Re: SetBufferCommitInfoNeedsSave and race conditions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: SetBufferCommitInfoNeedsSave and race conditions
Date
Msg-id 21346.1183060063@sss.pgh.pa.us
Whole thread Raw
In response to Re: SetBufferCommitInfoNeedsSave and race conditions  (Alvaro Herrera <alvherre@commandprompt.com>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane escribi�:
>> A quick grep suggests that VACUUM FULL might be at risk here.

> That particular case seems easily fixed since VACUUM FULL must hold an
> exclusive lock; and we can forcibly set sync commit for VACUUM FULL.

Uh, that wouldn't help.  The problem is that if VACUUM FULL is *looking
at* a recently-committed tuple, tqual.c might decide it can't set the
hint bit yet because it's not certain the commit record for that other
transaction is flushed.

We could possibly hack things so that inside a VACUUM FULL (maybe plain
vacuum too?), we prefer flushing xlog to leaving hint bits unset.
That's likely to be messy though.

Probably a cleaner and more robust answer is to make VACUUM FULL call
tqual.c again in the places where it currently assumes it can look
directly at the hint bits.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: SetBufferCommitInfoNeedsSave and race conditions
Next
From: imad
Date:
Subject: Re: write past chunk end in ExprContext / to_char