Re: oldest xmin is far in the past

From: John Snow <sleepwalker(dot)js(at)gmail(dot)com>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: oldest xmin is far in the past
Date: 2016-03-19 05:29:21
Message-ID: CAM+o-ApuKO=UMRZmkY6NwLrcqCZanXWmaThCgFFzY7jVz0mbRA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

There is no any long transaction neither prepared transaction.
#autovacuum_freeze_max_age = 200000000 - default value

I have 9.4.5 version. Also it all started after I've setup Slony
replication(mb just a coincidence). All tables in public schema have the
same "age", I believe this is weird.

How can I calculate how long DB can live in this stage?

2016-03-19 0:28 GMT+03:00 Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>:

> Hi,
>
> On 03/18/2016 09:42 AM, John Snow wrote:
>
>> Hi everyone!
>>
>> Trying to make VACUUM FREEZE on PG instance and keep getting this error:
>>
>> 2016-03-18 05:56:51 UTC 46750 WARNING: oldest xmin is far in the past
>> 2016-03-18 05:56:51 UTC 46750 HINT: Close open transactions soon to
>> avoid wraparound problems.
>> 2016-03-18 05:56:51 UTC 46750 DEBUG: transaction ID wrap limit is
>> 2654342112, limited by database with OID 1
>> 2016-03-18 05:56:51 UTC 46750 DEBUG: MultiXactId wrap limit is
>> 2147483648, limited by database with OID 12451
>>
>> Also "age" and "relfrozenxid" doesnt't change.
>>
>
> That probably means there's an old transaction somewhere - either a
> regular one (check pg_stat_activity) or a prepared one (pg_prepared_xacts).
>
> The meaning of "old" depends on autovacuum_freeze_max_age - what value is
> set in the session running the VACUUM FREEZE?
>
> regards
>
> --
> Tomas Vondra http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2016-03-19 05:39:25 Re: logger process infinite loop
Previous Message Peter Geoghegan 2016-03-19 05:00:22 Re: WIP: Covering + unique indexes.