Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dCkw3-0006vs-4B for pgsql-sql@arkaria.postgresql.org; Mon, 22 May 2017 10:51:35 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1dCkw2-0001Em-1B for pgsql-sql@arkaria.postgresql.org; Mon, 22 May 2017 10:51:34 +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 1dCkvz-0001Bp-Uv for pgsql-sql@postgresql.org; Mon, 22 May 2017 10:51:32 +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 1dCkvw-0001GY-P9 for pgsql-sql@postgresql.org; Mon, 22 May 2017 10:51:31 +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 v4MApRV0025638 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Mon, 22 May 2017 12:51:27 +0200 To: pgsql-sql@postgresql.org From: Sebastien FLAESCH Subject: TRUNCATE TABLE corrupts pg_class.relfilenode = pg_attrdef.pg_attrdef Organization: Four Js Development Tools Message-ID: <66def74b-633e-65a0-cf44-4d486f15ebd9@4js.com> Date: Mon, 22 May 2017 12:51:27 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.5.1 MIME-Version: 1.0 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 12:51:27 +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 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