From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Dave Peticolas <dave(at)krondo(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: locate DB corruption |
Date: | 2018-09-01 00:18:53 |
Message-ID: | e0334b31-f0ca-b0c2-6224-b07fe10037a8@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 08/31/2018 08:51 AM, Dave Peticolas wrote:
> On Fri, Aug 31, 2018 at 8:14 AM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com
> <mailto:adrian(dot)klaver(at)aklaver(dot)com>> wrote:
>
> On 08/31/2018 08:02 AM, Dave Peticolas wrote:
> > Hello, I'm running into the following error running a large query
> on a
> > database restored from WAL replay:
> >
> > could not access status of transaction 330569126
> > DETAIL: Could not open file "pg_clog/0C68": No such file or directory
>
>
> Postgres version?
>
>
> Right! Sorry, that original email didn't have a lot of info. This is
> 9.6.9 restoring a backup from 9.6.8.
>
> Where is the replay coming from?
>
>
> From a snapshot and WAL files stored in Amazon S3.
Seems the process is not creating a consistent backup.
How are they being generated?
> Are you sure you are not working across versions?
>
>
> I am sure, they are all 9.6.
>
> If not do pg_clog/ and 0C68 actually exist?
>
>
> pg_clog definitely exists, but 0C68 does not. I think I have
> subsequently found the precise row in the specific table that seems to
> be the problem. Specifically I can select * from TABLE where id = BADID
> - 1 or id = BADIDÂ + 1 and the query returns. I get the error if I select
> the row with the bad ID.
>
> Now what I'm not sure of is how to fix.
One thing I can think of is to rebuild from a later version of your S3
data and see if it has all the necessary files.
There is also pg_resetxlog:
https://www.postgresql.org/docs/9.6/static/app-pgresetxlog.html
I have not used it, so I can not offer much in the way of tips. Just
from reading the docs I would suggest stopping the server and then
creating a backup of $PG_DATA(if possible) before using pg_resetxlog.
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Shaun Savage | 2018-09-01 00:27:46 | Re: using a plpgsql function argument as a table column. |
Previous Message | Andres Freund | 2018-08-31 22:50:47 | Re: Autovacuum degrades all other operations by keeping all buffers dirty? |