On Thu, Jun 6, 2013 at 6:28 PM, Greg Stark <st...@mit.edu> wrote: > On Thu, Jun 6, 2013 at 1:39 PM, Heikki Linnakangas > <hlinnakan...@vmware.com> wrote: >> That will keep OldestXmin from advancing. Which will keep vacuum from >> advancing relfrozenxid/datfrozenxid. Which will first trigger the warnings >> about wrap-around, then stops new XIDs from being generated, and finally a >> forced shutdown. >> >> The forced shutdown will actually happen some time before going beyond 2 >> billion XIDs. So it is not possible to have a long-lived transaction, older >> than 2 B XIDs, still live in the system. But let's imagine that you somehow >> bypass the safety mechanism: > > Ah, so if you do the epoch in the page header thing or Robert's LSN > trick that I didn't follow then you'll need a new safety check against > this. Since relfrozenxid/datfrozenxid will no longer be necessary.
Nothing proposed here gets rid of either of those, that I can see. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
