Re: oldest xmin is far in the past - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: oldest xmin is far in the past
Date
Msg-id 16f29a07-1db8-9188-7202-d834466fe7ac@2ndquadrant.com
Whole thread Raw
In response to Re: oldest xmin is far in the past  (John Snow <sleepwalker.js@gmail.com>)
Responses Re: oldest xmin is far in the past
List pgsql-hackers
Hi,

On 03/19/2016 06:29 AM, John Snow wrote:
> There is no any long transaction neither prepared transaction.

Can you show us pg_stat_activity? Particularly the xmin values for 
backends attached to the two databases mentioned in the log (1 and 12451).

FWIW the second OID is a bit weird - the first OID assigned to normal 
objects is defined as 16384, and none of the so I wonder how you managed 
to create a database with such DB?

Unless it's one of the template databases, but I got different OIDs when 
I tried a fresh initdb on 9.4.

> #autovacuum_freeze_max_age = 200000000 - default value

After looking at the code a bit more, I see it uses some additional 
configuration options:

* freeze_min_age
* vacuum_freeze_min_age
* autovacuum_freeze_max_age (we already know this one)

What values are set for those?

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: pgbench stats per script & other stuff
Next
From: Fabien COELHO
Date:
Subject: Re: extend pgbench expressions with functions