Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iEbBe-0000EN-D1 for pgsql-performance@arkaria.postgresql.org; Sun, 29 Sep 2019 15:32:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1iEbBc-0002ts-Ak for pgsql-performance@arkaria.postgresql.org; Sun, 29 Sep 2019 15:32:36 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1iEbBc-0002sl-1v for pgsql-performance@lists.postgresql.org; Sun, 29 Sep 2019 15:32:36 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1iEbBU-0004c5-N5 for pgsql-performance@lists.postgresql.org; Sun, 29 Sep 2019 15:32:34 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id x8TFWNZP001797; Sun, 29 Sep 2019 11:32:23 -0400 From: Tom Lane To: Mariel Cherkassky cc: Laurenz Albe , pgsql-performance@lists.postgresql.org Subject: Re: sequence depends on many tables In-reply-to: References: Comments: In-reply-to Mariel Cherkassky message dated "Sun, 29 Sep 2019 09:05:15 +0300" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1795.1569771143.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Sun, 29 Sep 2019 11:32:23 -0400 Message-ID: <1796.1569771143@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Mariel Cherkassky writes: > seq_oid | classid | objid | objsubid | refclassid | refobjid | refobjsu= bid > | deptype > ---------+---------+-------+----------+------------+----------+---------= ----+--------- > 17188 | 1259 | 17188 | 0 | 1259 | 17190 | = 1 > | a > 16566 | 2604 | 16566 | 0 | 1259 | 17190 | = 1 > | a > 16704 | 2606 | 16704 | 0 | 1259 | 17190 | = 3 > | a > 16704 | 2606 | 16704 | 0 | 1259 | 17190 | = 5 > | a > 16704 | 2606 | 16704 | 0 | 1259 | 17190 | = 4 > | a > (5 rows) Well, those entries with objid =3D 16566 and 16704 are not for sequences, because the classid is wrong: 2604 is pg_attrdef, and 2606 is pg_constraint, so the second row is for a default expression belonging to table 17190 column 1, and the rest are for some kind of constraint involving columns 3,4,5 (maybe a check constraint?) In itself there's nothing wrong with these pg_depend entries, but it is odd that you have different objects with identical OIDs. Normally I'd only expect that to be possible once the OID counter has wrapped around ... but all these OIDs are small, which makes it seem unlikely that you've consumed enough OIDs to reach wraparound. Maybe you had a system crash, or did something weird with backup/recovery, causing the counter to get reset? Anyway, the short answer here is that neither objid nor refobjid should be considered sufficient to identify an object by themselves. You need to also check classid (refclassid), because OIDs are only guaranteed unique within a given system catalog. regards, tom lane