Re: spurious wrap-around shutdown

From: Andres Freund <andres(at)2ndquadrant(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: spurious wrap-around shutdown
Date: 2013-06-16 20:38:46
Message-ID: 20130616203846.GB17598@awork2.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2013-06-16 11:54:24 -0700, Jeff Janes 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
>
>
> postgres=# select txid_current();
> ERROR: database is not accepting commands to avoid wraparound data loss in
> database "jjanes"
> HINT: Stop the postmaster and use a standalone backend to vacuum that
> database.
> You might also need to commit or roll back old prepared transactions.
>
>
> 184,528,922 is well short of 2 billion, so what is going on?

I guess you're sure you don't have any old prepared xacts running
around?

> I thought maybe the ShmemVariableCache were not getting updated when vacuum
> finished, but if I restart the server (forcing shared memory to get rebuilt
> from disk) the condition continues.
>
> I tried setting a breakpoint on SetTransactionIdLimit, but that seems to
> get executed on startup before the -W flag takes effect, so I can't find it.
>
> Any tips on how to debug this? I figure the next step is running git
> bisect, but that is sure to be tedious.

I'd first add the actual xids limits that are assumed to be dangerous to
the error messages in GetNewTransactionId(). That already might give a
hint.

> I'm using a variant of the below to reach wraparound quicker, perhaps that
> is introducing a bug?
>
> http://www.postgresql.org/message-id/20130207203216.GE5172@alvh.no-ip.org

I don't really trust that patch because it skips loads of checks since
it only repeats part of the work that GetNewTransactionId does. I don't
immediately see what the problem that could cause though.
IIRC I had postes a patch in that thread that looped around
GetNewTransactionId() in that thread. It might be worthwile to test
whether that also reproduces the issue.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2013-06-16 20:48:08 Re: Improvement of checkpoint IO scheduler for stable transaction responses
Previous Message Andres Freund 2013-06-16 20:23:44 Re: Support for REINDEX CONCURRENTLY