On Sun, Dec 01, 2013 at 01:55:45PM +0100, Andres Freund wrote: > On 2013-12-01 13:33:42 +0100, Andres Freund wrote: > > On 2013-11-27 14:53:27 -0500, Noah Misch wrote: > > > How would you characterize the chances of this happening with default > > > *vacuum_freeze_*_age settings? Offhand, it seems you would need to > > > encounter > > > this bug during each of ~10 generations of autovacuum_freeze_max_age > > > before > > > the old rows actually become invisible. > > > > On second thought, it's quite possible to see problems before that > > leading to more problems. A single occurance of such a illegitimate > > increase in relfrozenxid can be enough to cause problems of a slightly > > different nature. > > As relfrozenxid has been updated we might now, or after vacuuming some > > other tables, become elegible to truncate the clog. In that case we'll > > get ERRORs about "could not access status of transaction" if the tuple > > hasn't been fully hinted when scanning it later.
Agreed. Probably, the use of hint bits and the low frequency with which TruncateCLOG() can actually remove something has kept this below the radar. > And indeed, a quick search shows up some threads that might suffer from > it: > bd7ee863f673a14ebf99d95562aee15e44b1d...@digi-pdc.digitilitiprod.int This system had multiple problems, a missing pg_subtrans file and a missing TOAST chunk for pg_attribute. I don't see a pg_clog problem connecting it to the freeze bug at hand. > caazpmnxfdrv72wdmbev5tcqobye_wvgseqrkqj0fizxmcyy...@mail.gmail.com This report is against PostgreSQL 8.1.11, which never had a commit like b4b6923. If a similar bug is at work, this older version acquired it through a different vector. > cak9ovjwvazlmdmrhmpg1+s37z16j+bz8fbarzspmrhsxxh-...@mail.gmail.com Possible match, but suggestions of lower-level problems cloud the diagnosis. Thanks, nm -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
