pg.ddx.io pgsql-bugs@postgresql.org mailing list archivehelp / color / mirror / Atom feed
Bogus pg_class.relminmxid value for pg_database 2+ messages / 2 participants [nested] [flat]
Commits from this thread: 2014-06-27 e86cfc4bbe b7e51d9c06 9eecc8a7ca Don't allow relminmxid to go backwards during VACUUM FULL
* Bogus pg_class.relminmxid value for pg_database @ 2013-09-23 10:41 Heikki Linnakangas <hlinnakangas@vmware.com> 0 siblings, 1 reply; 2+ messages in thread From: Heikki Linnakangas @ 2013-09-23 10:41 UTC (permalink / raw) To: pgsql-bugs; Alvaro Herrera <alvherre@2ndquadrant.com> Right after a fresh initdb on a 9.3 or master database: postgres=# select oid,relname,relminmxid from pg_class where relname='pg_database'; oid | relname | relminmxid ------+-------------+------------ 1262 | pg_database | 4244967297 (1 row) That bogus value seems to appear already some time during initdb. The relminmxid for all other tables is 1, which is correct. - Heikki -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs ^ permalink raw reply [nested|flat] 2+ messages in thread
* Re: Bogus pg_class.relminmxid value for pg_database @ 2014-06-27 15:58 Alvaro Herrera <alvherre@2ndquadrant.com> parent: Heikki Linnakangas <hlinnakangas@vmware.com> 0 siblings, 0 replies; 2+ messages in thread From: Alvaro Herrera @ 2014-06-27 15:58 UTC (permalink / raw) To: Heikki Linnakangas <hlinnakangas@vmware.com>; +Cc: pgsql-bugs Heikki Linnakangas wrote: > Right after a fresh initdb on a 9.3 or master database: > > postgres=# select oid,relname,relminmxid from pg_class where > relname='pg_database'; > oid | relname | relminmxid > ------+-------------+------------ > 1262 | pg_database | 4244967297 > (1 row) > > That bogus value seems to appear already some time during initdb. > The relminmxid for all other tables is 1, which is correct. I finally figured the source of this issue: it's caused by VACUUM FULL (executed by initdb while copying template1 into template0): we're missing a protection that relminmxid doesn't go backwards when swapping heaps. We already have such a check for xids. This is mostly innocuous, but I'm about to push the attached fix all the same, backpatched to 9.3. (The extra context lines make the patch very clear.) -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs Attachments:^ permalink raw reply [nested|flat] 2+ messages in threadbackwards-mxid.patch (text/x-diff, 904B) download
diff --git a/src/backend/commands/cluster.c b/src/backend/commands/cluster.c index 6f87170..46b41c1 100644 --- a/src/backend/commands/cluster.c +++ b/src/backend/commands/cluster.c @@ -869,14 +869,20 @@ copy_heap_data(Oid OIDNewHeap, Oid OIDOldHeap, Oid OIDOldIndex, /* * FreezeXid will become the table's new relfrozenxid, and that mustn't go * backwards, so take the max. */ if (TransactionIdPrecedes(FreezeXid, OldHeap->rd_rel->relfrozenxid)) FreezeXid = OldHeap->rd_rel->relfrozenxid; + /* + * MultiXactCutoff, similarly, shouldn't go backwards either. + */ + if (MultiXactIdPrecedes(MultiXactCutoff, OldHeap->rd_rel->relminmxid)) + MultiXactCutoff = OldHeap->rd_rel->relminmxid; + /* return selected values to caller */ *pFreezeXid = FreezeXid; *pCutoffMulti = MultiXactCutoff; /* Remember if it's a system catalog */ is_system_catalog = IsSystemRelation(OldHeap);
end of thread, other threads:[~2014-06-27 15:58 UTC | newest] Thread overview: 2+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2013-09-23 10:41 Bogus pg_class.relminmxid value for pg_database Heikki Linnakangas <hlinnakangas@vmware.com> 2014-06-27 15:58 ` Alvaro Herrera <alvherre@2ndquadrant.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox