From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Greg Stark <stark(at)mit(dot)edu> |
Cc: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, 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 17:54:39 |
Message-ID: | CA+TgmoaV_ypSnut1e0n1BDCpDX+xcZ+afFYrO_MCZC6A3b7Bag@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2013-06-07 18:06:59 | Re: SPGist "triple parity" concept doesn't work |
Previous Message | Robert Haas | 2013-06-07 17:52:38 | Re: Cost limited statements RFC |