Re: Could not open file "pg_subtrans/01EB" - Mailing list pgsql-admin

From Tom Lane
Subject Re: Could not open file "pg_subtrans/01EB"
Date
Msg-id 20970.1535298691@sss.pgh.pa.us
Whole thread Raw
In response to Could not open file "pg_subtrans/01EB"  (Mariel Cherkassky <mariel.cherkassky@gmail.com>)
Responses Re: Could not open file "pg_subtrans/01EB"  (Mariel Cherkassky <mariel.cherkassky@gmail.com>)
List pgsql-admin
Mariel Cherkassky <mariel.cherkassky@gmail.com> writes:
> I'm trying to investigate a database of one of our clients. The database
> version is 9.2.5.

1. Fire their DBA for dereliction of duty.

2. Update to the last available release of 9.2.x (9.2.24, looks like).

3. Vacuum everything and see if it gets better.

Vacuuming may or may not fix the observed data corruption problems, but
it's silly to ignore the fact that they're missing four years worth
of bug fixes in that branch.  In particular I'm noticing the first
entry in the change notes for 9.2.6, which recommends "vacuuming all
tables in all databases while having vacuum_freeze_table_age set to zero":
https://www.postgresql.org/docs/9.2/static/release-9-2-6.html
That problem as-described seems to involve rows disappearing, rather than
getting duplicated, but I wouldn't rule out that it could also have
symptoms like this.

If that doesn't fix things, you could then try:

4. Manually eliminate duplicate rows by identifying which one of each pair
seems older and deleting it with DELETE ... WHERE ctid = '(x,y)'.  Then
reindex to confirm no duplicates remain.

But you still need step 2, to reduce the odds the problem will recur.

            regards, tom lane


pgsql-admin by date:

Previous
From: Mariel Cherkassky
Date:
Subject: Re: Could not open file "pg_subtrans/01EB"
Next
From: Mariel Cherkassky
Date:
Subject: Re: Could not open file "pg_subtrans/01EB"