Re: Could not open file "pg_subtrans/01EB"

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)com>
Cc: pgsql-admin(at)lists(dot)postgresql(dot)org
Subject: Re: Could not open file "pg_subtrans/01EB"
Date: 2018-08-26 15:51:31
Message-ID: 20970.1535298691@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

Mariel Cherkassky <mariel(dot)cherkassky(at)gmail(dot)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

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message Mariel Cherkassky 2018-08-26 16:42:06 Re: Could not open file "pg_subtrans/01EB"
Previous Message Mariel Cherkassky 2018-08-26 12:10:57 Re: Could not open file "pg_subtrans/01EB"