| 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: | 21346.1183060063@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | imad | 2007-06-28 19:53:31 | Re: write past chunk end in ExprContext / to_char |
| Previous Message | Alvaro Herrera | 2007-06-28 19:29:48 | Re: SetBufferCommitInfoNeedsSave and race conditions |