Re: oldest xmin is far in the past

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: oldest xmin is far in the past
Дата
Msg-id 16f29a07-1db8-9188-7202-d834466fe7ac@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: oldest xmin is far in the past  (John Snow <sleepwalker.js@gmail.com>)
Ответы Re: oldest xmin is far in the past  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список 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 по дате отправления:

Предыдущее
От: Fabien COELHO
Дата:
Сообщение: Re: pgbench stats per script & other stuff
Следующее
От: Fabien COELHO
Дата:
Сообщение: Re: extend pgbench expressions with functions