I: "ERROR: could not access status of transaction" (after upgrding from 9.3.2 to 9.3.4?)

From: "Cassiano, Marco" <mcassiano(at)manord(dot)com>
To: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: I: "ERROR: could not access status of transaction" (after upgrding from 9.3.2 to 9.3.4?)
Date: 2014-07-28 12:27:24
Message-ID: 1361CEF686657C41A139AD8C3145632B2A01BB0C@E2010-MB1.manord.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Hi all,

first of all, thank you Jay (jayknowsunix) for your answer.

With further investigation, we found other two cases of missing pg_clog files.

I ran a fsck against the filsystem and everything is OK (whew!!)

So the question is still : why are they missing ?

I noticed that in my pg_clog directory the oldest file is 040D (date 3/9/2014).
The missing files were 03FA, 03CF and 03E3.
It seems that something deleted all files prior to 3/9/2014 (Sunday).
I searched through postgresql logs but didn't find anything that could explain the reason why these files are missing.

Another option to explain the problem could be that it's correct that those files are gone but the problem is that somewhere in the database there's something still referring to them that wasn't cleared... Could it be possible ?

Anyway, in the three cases we found, the dump/delete/reload table system worked. Luckily the three tables allowed such a procedure (small tables, not a lot of referential integrity, not frequently accessed)

I will appreciate any idea, experience, suggestion you will share

Thanks

Marco

-----Messaggio originale-----
Da: pgsql-admin-owner(at)postgresql(dot)org [mailto:pgsql-admin-owner(at)postgresql(dot)org] Per conto di Cassiano, Marco
Inviato: lunedì 21 luglio 2014 11:27
A: pgsql-admin(at)postgresql(dot)org
Oggetto: [ADMIN] "ERROR: could not access status of transaction" (after upgrding from 9.3.2 to 9.3.4?)

Hi all,

every weekend we use to run a batch that makes reindex/cluster of our main db.

This weekend we observed this error in the log :

2014-07-19 23:00:41 GMT 172.30.2.200(53959) dba mdn 1265998975 53caf874.6826 - ERROR: could not access status of transaction 1067517164
2014-07-19 23:00:41 GMT 172.30.2.200(53959) dba mdn 1265998975 53caf874.6826 - DETAIL: Could not open file "pg_clog/03FA": No such file or directory.
2014-07-19 23:00:41 GMT 172.30.2.200(53959) dba mdn 1265998975 53caf874.6826 - STATEMENT: cluster pk__cat_taglio on "anamat"."cat_taglio"

The previous weekend the job worked fine.

The only thing that happened in the middle (AFAIK) is that on the 17th we apply the minor upgrade of postgresql from 9.3.2 to 9.3.4.

Can you please help me to understand the cause of this corruption, how much is serious and the its correct resolution ?

By the way the data in the table seems ok : i can dump the table, I can select the data inside it.

SInce this table doesn't change frequently, we are considering a dump/delete/restore. Will this fix the problem in yuor opinion ?

Thanks a lot

Marco Cassiano

--
Sent via pgsql-admin mailing list (pgsql-admin(at)postgresql(dot)org) To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Rural Hunter 2014-07-28 13:10:32 Re: Very slow planning performance on partition table
Previous Message Rural Hunter 2014-07-28 07:01:19 Re: Very slow planning performance on partition table