From: Tom Lane <tgl@sss.pgh.pa.us>
To: Mariel Cherkassky <mariel.cherkassky@gmail.com>
cc: pgsql-admin@lists.postgresql.org
Subject: Re: Could not open file "pg_subtrans/01EB"
In-reply-to: 
 <CA+t6e1=fYtSwS=X4mZ=gS-HP6N9Sc4gacZB4uR_+05wAwrzreA@mail.gmail.com>
References: 
 <CA+t6e1=fYtSwS=X4mZ=gS-HP6N9Sc4gacZB4uR_+05wAwrzreA@mail.gmail.com>
Comments: In-reply-to Mariel Cherkassky <mariel.cherkassky@gmail.com>
	message dated "Sun, 26 Aug 2018 12:29:32 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <20969.1535298691.1@sss.pgh.pa.us>
Date: Sun, 26 Aug 2018 11:51:31 -0400
Message-ID: <20970.1535298691@sss.pgh.pa.us>
Precedence: bulk

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