| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Simon Riggs" <simon(at)2ndquadrant(dot)com> |
| 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-29 00:23:37 |
| Message-ID: | 25977.1183076617@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Simon Riggs" <simon(at)2ndquadrant(dot)com> writes:
> On Thu, 2007-06-28 at 15:16 -0400, Tom Lane wrote:
>> 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.
Flush what prior to the scan?
The methodology I suggested earlier (involving tracking LSN only at the
level of pg_clog pages) isn't going to make that work, unless you
somehow force the XID counter forward to the next page boundary.
It might be that that level of tracking is too coarse anyway, since
it essentially says that you can't hint any transaction until the
next 32K-transaction boundary is reached.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-06-29 00:25:46 | Re: write past chunk end in ExprContext / to_char |
| Previous Message | Alvaro Herrera | 2007-06-28 23:50:55 | Re: lazy vacuum sleeps with exclusive lock on table |