Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1XPFws-00067e-06 for pgsql-admin@arkaria.postgresql.org; Wed, 03 Sep 2014 19:10:30 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1XPFwq-0004ns-QJ for pgsql-admin@arkaria.postgresql.org; Wed, 03 Sep 2014 19:10:28 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XPFwp-0004nh-AQ for pgsql-admin@postgresql.org; Wed, 03 Sep 2014 19:10:27 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1XPFwl-0000Mm-JS for pgsql-admin@postgresql.org; Wed, 03 Sep 2014 19:10:25 +0000 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by gateway2.nyi.internal (Postfix) with ESMTP id 0E82D20B2D for ; Wed, 3 Sep 2014 15:10:21 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute3.internal (MEProxy); Wed, 03 Sep 2014 15:10:21 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=aklaver.com; h= message-id:date:from:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; s=mesmtp; bh=+k12p9oSKz8Hq7UijwjQww67BBI=; b=V/wCUlE9NAIz6VRadePIHyfrdcK7 CUC8q7vUVQide5HnQJvfHoMgy1jHK4j1SBKv+pcsLuFrHCMvIIxCNZNSlLAHQqs8 +k84tYzJeR+KvBadcFwUttqNXK8G0RyOFHSOv7WWiqZgHrG8659Zaxu+aE/jv1+c Er1FjCsd9Wns54s= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=message-id:date:from:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; s=smtpout; bh=+k12p9oSKz8Hq7UijwjQww 67BBI=; b=QAU4slMjJY+64ZL1OoPJDgjCgbmaikPU/Jf13JeHEJuf0zsm/K6QtI d6l2rlwi6xggMybqI7bzEbCG9J8oET6YXnsQsX0HmtvFdvuQm8lMOPesxSK5fedM ADL7xIVyshQxvEBiFA3TD000JtljJBhImxAIIlHUtMy+9tfLddhRg= X-Sasl-enc: TbXh9ci/60coTAxuUAck4TUDAyfIkSky58u564o7AoIV 1409771420 Received: from [192.168.1.5] (unknown [174.21.177.1]) by mail.messagingengine.com (Postfix) with ESMTPA id 58612C00916; Wed, 3 Sep 2014 15:10:20 -0400 (EDT) Message-ID: <5407679B.2030906@aklaver.com> Date: Wed, 03 Sep 2014 12:10:19 -0700 From: Adrian Klaver User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Alanoly Andrews , 'Craig James' CC: "pgsql-admin@postgresql.org" , "pgsql-general@postgresql.org" Subject: Re: [GENERAL] Re: Cannot retrieve images inserted through VB and odbc, after a table reorganization. References: <6909b219ecae4d41b431efdaf6c953a3@Exch2.invera.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org On 09/03/2014 09:26 AM, Alanoly Andrews wrote: > *Hi Craig,* > > ** > > *I’m reloading into the very same database. * > > *If I insert a new row into the table (through VB/ODBC), I’m able to > retrieve it (again from VB). But if after inserting the new row, I do a > reorg of the table (eg. with a “cluster table”), I’m no longer able to > retrieve that same row. In short, as long as the newly inserted rows are > not “re-written” in some way, they can be retrieved through VB/ODBC. * To follow up on my previous post with regards to OIDs. That may have been a wrong fork. A little testing: test=# CREATE TABLE image ( name text, raster oid ); test=# create index img_idx on image (raster); test=# INSERT INTO image (name, raster) VALUES ('another beautiful image', lo_import('/home/aklaver/Pictures/IMG_0359JPG')); test=# INSERT INTO image (name, raster) VALUES ('another beautiful image', lo_import('/home/aklaver/Pictures/IMG_0360.JPG')); test=# INSERT INTO image (name, raster) VALUES ('another beautiful image', lo_import('/home/aklaver/Pictures/IMG_0361.JPG')); test=# select oid, relfilenode from pg_class where relname ='image'; oid | relfilenode --------+------------- 532144 | 532175 test=# cluster image using img_idx; CLUSTER test=# select oid, relfilenode from pg_class where relname ='image'; oid | relfilenode --------+------------- 532144 | 532182 Note the OID for the table stays the same but the relfilenode changes. This also happens with the other situations you describe(unless you use --oids with pg_dump). So to revise my previous statement, my guess is your VB/ODBC code is using the relfilenode value to refer to the table and when that changes it cannot find it any more. > > ** > > *Alanoly.* > -- Adrian Klaver adrian.klaver@aklaver.com -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin