Re: Freezing without write I/O

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Greg Stark <stark(at)mit(dot)edu>
Cc: Robert Haas <robertmhaas(at)gmail(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-06 12:39:27
Message-ID: 51B082FF.2040100@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06.06.2013 15:16, Greg Stark wrote:
> On Fri, May 31, 2013 at 3:04 AM, Robert Haas<robertmhaas(at)gmail(dot)com> wrote:
>> Even at a more modest 10,000 tps, with default
>> settings, you'll do anti-wraparound vacuums of the entire cluster
>> about every 8 hours. That's not fun.
>
> I've forgotten now. What happens if you have a long-lived transaction
> still alive from> 2B xid ago?

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:

After wraparound, old tuples will look like being in the future, and
will become invisible to new transactions. That happens even if there
are no old transactions around. I'm not sure what exactly will happen if
there is still a transaction alive with an XID and/or snapshots older
than 2^31 XIDs. New tuples that are not supposed to be visible to the
old snapshot would suddenly become visible, I guess.

- Heikki

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2013-06-06 13:21:33 Re: Redesigning checkpoint_segments
Previous Message Kevin Grittner 2013-06-06 12:31:26 Re: Redesigning checkpoint_segments