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

From: Cliff Pratt <enkiduonthenet(at)gmail(dot)com>
To: "Cassiano, Marco" <mcassiano(at)manord(dot)com>
Cc: "pgsql-admin(at)postgresql(dot)org" <pgsql-admin(at)postgresql(dot)org>
Subject: Re: I: "ERROR: could not access status of transaction" (after upgrding from 9.3.2 to 9.3.4?)
Date: 2014-07-29 00:12:53
Message-ID: CADXosE+wFvrJ6fckRHe94PjBVKGJccA3pq7hqm1ZiuV4GQw2HQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

If there is nothing in the *postgres* logs, could it be something outside
of postgres that is removing the files? Some rogue "clean up script" maybe.

Cheers,

Cliff

On Tue, Jul 29, 2014 at 12:27 AM, Cassiano, Marco <mcassiano(at)manord(dot)com>
wrote:

> 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
>
>
> --
> 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

Browse pgsql-admin by date

  From Date Subject
Next Message Rural Hunter 2014-07-29 08:21:18 Re: Very slow planning performance on partition table
Previous Message Rural Hunter 2014-07-29 00:10:35 Re: Very slow planning performance on partition table