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:
> BD7EE863F673A14EBF99D95562AEE15E44B1DA71@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_wvGSeqRkQj0FizXmCYyaPQ@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-4GQ@mail.gmail.com
Possible match, but suggestions of lower-level problems cloud the diagnosis.
Thanks,
nm
--
Noah Misch
EnterpriseDB http://www.enterprisedb.com