Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dClCp-0007vS-2x for pgsql-sql@arkaria.postgresql.org; Mon, 22 May 2017 11:08:55 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dClCo-00072q-Lq for pgsql-sql@arkaria.postgresql.org; Mon, 22 May 2017 11:08:54 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dClBn-0005FP-S5 for pgsql-sql@postgresql.org; Mon, 22 May 2017 11:07:52 +0000 Received: from mail231.strasbourg.4js.com ([92.103.31.231]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1dClBk-0000Ls-Qf for pgsql-sql@postgresql.org; Mon, 22 May 2017 11:07:50 +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 v4MB7kf8027798 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 22 May 2017 13:07:46 +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> From: Sebastien FLAESCH Organization: Four Js Development Tools Message-ID: <291ca3cf-79af-c161-4213-182c35e43fe6@4js.com> Date: Mon, 22 May 2017 13:07:46 +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: <66def74b-633e-65a0-cf44-4d486f15ebd9@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:07:46 +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 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