From: | Dave Peticolas <dave(at)krondo(dot)com> |
---|---|
To: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
Cc: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: locate DB corruption |
Date: | 2018-09-02 00:53:04 |
Message-ID: | CAPRbp046jzSvMy+0HQMFgVvBYpMNMjgTyi2a62_MR+FZKvGqvg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Sat, Sep 1, 2018 at 5:09 PM Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
wrote:
> On 09/01/2018 04:45 PM, Dave Peticolas wrote:
>
> > Well restoring from a backup of the primary does seem to have fixed the
> > issue with the corrupt table.
>
> Pretty sure it was not that the table was corrupt but that transaction
> information was missing from pg_clog.
>
> In a previous post you mentioned you ran tar to do the snapshot of
> $PG_DATA.
>
> Was there any error when tar ran the backup that caused you problems?
>
Well the interesting thing about that is that although the bad table was
originally discovered in a DB restored from a snapshot, I subsequently
discovered it in the real-time clone of the primary from which the backups
are made. So somehow the clone's table became corrupted. The same table was
not corrupt on the primary, but I have discovered an error on the primary
-- it's in the thread I posted today. These events seem correlated in time,
I'll have to mine the logs some more.
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Peticolas | 2018-09-02 01:31:01 | Re: error in vacuum |
Previous Message | Dave Peticolas | 2018-09-02 00:28:33 | Re: error in vacuum |