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
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 |