spurious wrap-around shutdown

From: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
To: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: spurious wrap-around shutdown
Date: 2013-06-18 02:55:44
Message-ID: CAMkU=1xDr+fjZ87RVz2458FYgUpgPcBV8zik5widYw+Qttu4rA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Jun 16, 2013 at 11:54 AM, Jeff Janes
<jeff(dot)janes(at)gmail(dot)com<javascript:_e({}, 'cvml',
'jeff(dot)janes(at)gmail(dot)com');>
> wrote:

> In 9.3 HEAD I am getting what seems to be spurious wrap-around shutdowns.
>
>
> postgres=# SELECT datname, datfrozenxid, age(datfrozenxid) FROM
> pg_database;
>
> datname | datfrozenxid | age
> -----------+--------------+-----------
> template1 | 2621759843 | 0
> template0 | 2621759843 | 0
> postgres | 2571759843 | 50000000
> jjanes | 2437230921 | 184528922
>

While the behavior is weird, it is not a regression (also present in 9.2
with suitable changes in timing) and the shutdown is not spurious.

If I execute the above query immediately after the shutdown, I see what I
would expect, jjanes has an age of about 2^31.

The one table that is holding everything back is already getting autovac
for wraparound at that point, and eventually that vacuum finishes. When
done, pg_class and pg_database are updated (I don't know how they get
updated without trying to assign another transaction), and then I get the
above query results.

I would think the database would re-allow new transactions at this point,
but it does not. I don't know why.

Since this isn't a regression in 9.3, I probably won't pursue it any more
at this time, unless encouraged to.

Cheers,

Jeff

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2013-06-18 04:06:08 Re: SET work_mem = '1TB';
Previous Message Peter Eisentraut 2013-06-18 02:48:02 Re: How do we track backpatches?