Skip site navigation (1) Skip section navigation (2)

Re: SetBufferCommitInfoNeedsSave and race conditions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SetBufferCommitInfoNeedsSave and race conditions
Date: 2007-06-28 19:47:43
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Alvaro Herrera <alvherre(at)commandprompt(dot)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

In response to

pgsql-hackers by date

Next:From: imadDate: 2007-06-28 19:53:31
Subject: Re: write past chunk end in ExprContext / to_char
Previous:From: Alvaro HerreraDate: 2007-06-28 19:29:48
Subject: Re: SetBufferCommitInfoNeedsSave and race conditions

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group