| From: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com>, "Pavan Deolasee" <pavan(dot)deolasee(at)gmail(dot)com>, "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: SetBufferCommitInfoNeedsSave and race conditions |
| Date: | 2007-06-28 22:09:36 |
| Message-ID: | 1183068576.3589.5.camel@silverbirch.site |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, 2007-06-28 at 15:16 -0400, Tom Lane wrote:
> Heikki Linnakangas <heikki(at)enterprisedb(dot)com> writes:
> > AFAICS, we can just simply remove the assertion. But is there any
> > codepaths that assume that after calling HeapTupleSatisfiesSnapshot, all
> > appropriate hint bits are set?
>
> There had better not be, since we are going to postpone setting hint
> bits for recently-committed transactions as part of the async-commit
> patch.
>
> A quick grep suggests that VACUUM FULL might be at risk here.
No we're clear: I caught that issue specifically for VACUUM FULL fairly
early on. VF assumes all hint bits are set after the first scan, so we
flush prior to the scan to ensure its safe to set the hint bits. There
are no concurrent hint bit setters, so we are good.
--
Simon Riggs
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2007-06-28 22:15:28 | Re: lazy vacuum sleeps with exclusive lock on table |
| Previous Message | Alvaro Herrera | 2007-06-28 21:16:54 | lazy vacuum sleeps with exclusive lock on table |