Re: Freezing without write I/O

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Greg Stark <stark(at)mit(dot)edu>, Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Freezing without write I/O
Date: 2013-06-07 18:08:10
Message-ID: 51B2218A.4000905@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 07.06.2013 20:54, Robert Haas wrote:
> On Thu, Jun 6, 2013 at 6:28 PM, Greg Stark<stark(at)mit(dot)edu> wrote:
>> On Thu, Jun 6, 2013 at 1:39 PM, Heikki Linnakangas
>> <hlinnakangas(at)vmware(dot)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.

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.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2013-06-07 18:27:10 Re: Parallell Optimizer
Previous Message Tom Lane 2013-06-07 18:06:59 Re: SPGist "triple parity" concept doesn't work