On 7 June 2013 19:08, Heikki Linnakangas wrote:
On 07.06.2013 20:54, Robert Haas wrote:

On Thu, Jun 6, 2013 at 6:28 PM, Greg Starkwrote:
On Thu, Jun 6, 2013 at 1:39 PM, Heikki Linnakangas
That will keep OldestXmin from advancing. Which will keep vacuum from
advancing relfrozenxid/datfrozenxid. Which will first trigger the
about wrap-around, then stops new XIDs from being generated, and finally
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,
than 2 B XIDs, still live in the system. But let's imagine that you
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.

Right. The meaning of relfrozenxid/datfrozenxid changes somewhat; it no
longer means that all XIDs older than frozenxid are replaced with FrozenXid.
Instead, it will mean that all XIDs older than frozenxid are committed, ie.
all dead tuples older than that have been vacuumed away.
Now that I consider Greg's line of thought, the idea we focused on
here was about avoiding freezing. But Greg makes me think that we may
also wish to look at allowing queries to run longer than one epoch as
well, if the epoch wrap time is likely to come down substantially.

To do that I think we'll need to hold epoch for relfrozenxid as well,
amongst other things.

  Simon Riggs http://www.2ndQuadrant.com/
  PostgreSQL Development, 24x7 Support, Training & Services

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 25 of 39 | next ›
Discussion Overview
grouppgsql-hackers @
postedMay 30, '13 at 1:34p
activeAug 30, '13 at 6:34p



site design / logo © 2021 Grokbase