Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1
Date
Msg-id 20131120140726.GE25406@awork2.anarazel.de
Whole thread Raw
In response to Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1  (Kevin Grittner <kgrittn@ymail.com>)
Responses Re: Data corruption issues using streaming replication on 9.0.14/9.2.5/9.3.1  (Kevin Grittner <kgrittn@ymail.com>)
List pgsql-hackers
On 2013-11-20 05:59:58 -0800, Kevin Grittner wrote:
> Andres Freund <andres@2ndquadrant.com> wrote:
> > On 2013-11-20 05:30:39 -0800, Kevin Grittner wrote:
>
> >> Wouldn't a database VACUUM FREEZE fix it, with WAL-logged
> >> writing of everything that doesn't yet have hint bits set?
> >
> > Besides also being pretty expensive it still wouldn't correct the
> > clog - and we don't always rely on hint bits.
>
> I'm talking about after a fix is deployed, fixing up the possible
> corruption.  Can you explain where VACUUM FREEZE would not suffice?
> I don't know of anywhere that we have hint bits set for a tuple and
> we go fetch the clog bits in spite of that.

There's several places. Grep for TransactionIdDidCommit() and ignore the
bits in tqual.c. Many of the remaining ones do not look at hint bits.

> I don't understand
> where that would make sense; especially since I thought that a
> database FREEZE followed by a checkpoint releases old clog space
> anyway.

It only releases them up to the (cluster wide) xmin horizon. So if there
are older snapshots or prepared xacts around...

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Boszormenyi Zoltan
Date:
Subject: ECPG infrastructure changes, part 3, was: Re: ECPG fixes
Next
From: Boszormenyi Zoltan
Date:
Subject: ECPG infrastructure changes, part 4, was: Re: ECPG fixes