Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dClIt-0008H9-RC for pgsql-sql@arkaria.postgresql.org; Mon, 22 May 2017 11:15:11 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dClIt-0000YD-7o for pgsql-sql@arkaria.postgresql.org; Mon, 22 May 2017 11:15:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dClHu-0007Ck-48 for pgsql-sql@postgresql.org; Mon, 22 May 2017 11:14:10 +0000 Received: from mail231.strasbourg.4js.com ([92.103.31.231]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dClHq-0001eP-KH for pgsql-sql@postgresql.org; Mon, 22 May 2017 11:14:09 +0000 Received: from [10.0.40.29] (orion.strasbourg.4js.com [10.0.40.29]) (authenticated bits=0) by mail231.strasbourg.4js.com (8.14.4/8.14.4/Debian-4+deb7u1) with ESMTP id v4MBE5c0028220 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 22 May 2017 13:14:05 +0200 Subject: Re: TRUNCATE TABLE corrupts pg_class.relfilenode = pg_attrdef.pg_attrdef To: pgsql-sql@postgresql.org References: <66def74b-633e-65a0-cf44-4d486f15ebd9@4js.com> <291ca3cf-79af-c161-4213-182c35e43fe6@4js.com> From: Sebastien FLAESCH Organization: Four Js Development Tools Message-ID: <89f3d1ce-f11f-dfab-c780-50fa3d5836e9@4js.com> Date: Mon, 22 May 2017 13:14:05 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 In-Reply-To: <291ca3cf-79af-c161-4213-182c35e43fe6@4js.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.1 at mail231 X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.4.3 (mail231.strasbourg.4js.com [10.10.0.1]); Mon, 22 May 2017 13:14:05 +0200 (CEST) X-Pg-Spam-Score: -1.9 (-) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-sql Precedence: bulk Sender: pgsql-sql-owner@postgresql.org Obviously pg_class.relfilenode can change when truncating tables: test1=> select relfilenode from pg_class where relname = 'mytab'; relfilenode ------------- 6904188 (1 row) test1=> truncate table mytab; TRUNCATE TABLE test1=> select relfilenode from pg_class where relname = 'mytab'; relfilenode ------------- 6904189 (1 row) Seb On 05/22/2017 01:07 PM, Sebastien FLAESCH wrote: > Seems that the correct join condition should be: > > (pg_class.oid = pg_attrdef.adrelid) > > I don't know why we have used pg_class.relfilenode... > > So this should be the correct SELECT statement: > > test1=> select a.adsrc from pg_class p join pg_attrdef a on (p.oid = a.adrelid) where lower(p.relname) = lower('mytab'); > adsrc > ------------------------------------- > nextval('mytab_pkey_seq'::regclass) > (1 row) > > > Can someone confirm? > > Thanks! > Seb > > > On 05/22/2017 12:51 PM, Sebastien FLAESCH wrote: >> Hi all, >> >> Testing with Postgresql 9.6rc1 (but also detected with prior versions): >> >> It is normal that a TRUNCATE TABLE statement changes the table/sequence relation in pg_attrdef? >> >> test1=> create table mytab ( pkey serial, name varchar(10) ); >> test1=> select a.adsrc from pg_class p join pg_attrdef a on (p.relfilenode = a.adrelid) where lower(p.relname) = lower('mytab'); >> adsrc >> ------------------------------------- >> nextval('mytab_pkey_seq'::regclass) >> (1 row) >> >> test1=> truncate table mytab; >> TRUNCATE TABLE >> test1=> select a.adsrc from pg_class p join pg_attrdef a on (p.relfilenode = a.adrelid) where lower(p.relname) = lower('mytab'); >> adsrc >> ------- >> (0 rows) >> >> test1=> select adrelid, adsrc from pg_attrdef where adsrc like '%mytab%'; >> adrelid | adsrc >> ---------+------------------------------------- >> 6904163 | nextval('mytab_pkey_seq'::regclass) >> (1 row) >> >> >> Are we mis-using the condition (p.relfilenode = a.adrelid) in the first SELECT? >> >> How can we easily check if a table is defined with a SERIAL type? >> >> Thanks! >> Seb >> >> > > > -- Sent via pgsql-sql mailing list (pgsql-sql@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-sql