Yes. And we solved the problem.
We looked into the pg_subtrans and found that we had subrans pending from
January 25th. We investigated more and found that I large sql was executed
on Streaming standby around that date.
More digging we found the date of the below alert is also near:
WARNING: olde
On 02/12/2016 04:03 PM, AI Rumman wrote:
In pg_subtrans, I have files like:
Are you sure you are looking at the same database cluster in all the cases?
What does:
SELECT datname, age(datfrozenxid) FROM pg_database;
give you?
$ ls -lrt | more
total 1269436
-rw--- 1 postgre
In pg_subtrans, I have files like:
>
> $ ls -lrt | more
> total 1269436
> -rw--- 1 postgres postgres 262144 Jan 25 18:49 D907
> -rw--- 1 postgres postgres 262144 Jan 25 18:54 D908
> -rw--- 1 postgres postgres 262144 Jan 25 18:58 D909
> -rw--- 1 postgres postgres 262144 Jan 25 18:59
Used this query in each of the database::
SELECT t.relname, l.database, l.locktype, l.pid , l.mode, l.granted,
p.current_query, p.query_start ,p.waiting
FROM pg_locks as l
INNER JOIN pg_stat_all_tables t
on l.relation = t.relid
INNER JOIN pg_stat_activity as p
on l.pid = p.procpid ;
No luck. At p
On 02/12/2016 03:10 PM, AI Rumman wrote:
I checked it and I did not find any log running sql or any open
transaction. Not even in pg_prepared_xacts.
And it looks like pg_catalog database is making the alarm.
Any other idea please, where I need to look into.
Should have added:
select * from pg
On 02/12/2016 03:10 PM, AI Rumman wrote:
I checked it and I did not find any log running sql or any open
transaction. Not even in pg_prepared_xacts.
And it looks like pg_catalog database is making the alarm.
Any other idea please, where I need to look into.
select * from pg_locks
http://www.p
I checked it and I did not find any log running sql or any open
transaction. Not even in pg_prepared_xacts.
And it looks like pg_catalog database is making the alarm.
Any other idea please, where I need to look into.
Thanks.
On Fri, Feb 12, 2016 at 3:05 PM, Adrian Klaver
wrote:
> On 02/12/201
On 02/12/2016 02:56 PM, AI Rumman wrote:
Hi,
I am running Postgresql 9.1 and I can see the datfrozenxid is going high
and vacuum process is not bringing it down. And this has been happening
on template1 database.
2016-02-12 16:51:50.400 CST [19445][@] : [13-1] WARNING: oldest
xmin is f
Hi,
I am running Postgresql 9.1 and I can see the datfrozenxid is going high
and vacuum process is not bringing it down. And this has been happening on
template1 database.
2016-02-12 16:51:50.400 CST [19445][@] : [13-1] WARNING: oldest xmin is
> far in the past
> 2016-02-12 16:51:50.400 CST [194
