Re: [HACKERS] oldest xmin is far in the past

2016-03-20 Thread Jim Nasby
On 3/19/16 11:32 AM, Tomas Vondra wrote: 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). F

[HACKERS] oldest xmin is far in the past

2016-03-20 Thread John Snow
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:

Re: [HACKERS] oldest xmin is far in the past

2016-03-19 Thread Tomas Vondra
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

Re: [HACKERS] oldest xmin is far in the past

2016-03-18 Thread John Snow
There is no any long transaction neither prepared transaction. #autovacuum_freeze_max_age = 2 - 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

Re: [HACKERS] oldest xmin is far in the past

2016-03-18 Thread Tomas Vondra
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 pr