From: | Jeff Janes <jeff(dot)janes(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | 9.4 wrap around issues |
Date: | 2014-05-05 22:04:04 |
Message-ID: | CAMkU=1wbi5AfHyTAwdkAwEaSE_mc00i4y_7Ojhp1Y-8SgciO_Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
While stress testing the crash-recovery system, I keep running into
wraparound shutdowns that I think should not be occurring. I go out of my
way give autovac a chance to complete every now and then, more often than
it should need to in order to keep up with the xid usage.
I think the problem traces down to the fact that updating
pg_database.datfrozenxid is WAL logged, but
updating ShmemVariableCache->oldestXid is not.
So a crash at just the right time means that the databases no longer think
they need to be vacuumed for wrap around, but the system as a whole thinks
that they do.
Should crash recovery end with the system reading the recovered pg_database
and recomputing ShmemVariableCache->oldestXid ?
I don't know that any non-pathological case could trigger this in
production. But 2^32 is not getting any larger, while maximum common
database throughput and size is.
I bisect this down to f9b50b7c18c8ce7de1fee59409fe2 "Fix removal of files
in pgstats directories". I think that before that commit, the leftover
stats file was somehow tricking the system into vacuuming the databases
more aggressively following a crash.
Cheers,
Jeff
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2014-05-05 22:50:59 | Re: Recursive ReceiveSharedInvalidMessages not safe |
Previous Message | Peter Geoghegan | 2014-05-05 21:23:13 | Re: 9.4 release notes |