| From: | "Mikheev, Vadim" <vmikheev(at)SECTORBASE(dot)COM> |
|---|---|
| To: | "'Tom Lane'" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | The Hermit Hacker <scrappy(at)hub(dot)org>, Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, pgsql-hackers(at)postgresql(dot)org |
| Subject: | RE: Beta 6 Regression results on Redat 7.0. |
| Date: | 2001-03-21 01:23:24 |
| Message-ID: | 8F4C99C66D04D4118F580090272A7A234D333C@sectorbase1.sectorbase.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Further note: this bug does not arise in 7.0.* because in that code,
> BufferSync will only pin buffers that have been dirtied in the current
> transaction. This cannot affect a concurrent FlushRelationBuffers,
> which should be holding exclusive lock on the table it's flushing.
>
> Or can it? The above is safe enough for user tables, but on system
> tables we have a bad habit of releasing locks early. It seems possible
> that a VACUUM on a system table might see pins due to BufferSyncs
> running in concurrent transactions that have altered that system table.
>
> Perhaps this issue does explain some of the reports of
> FlushRelationBuffers failure that we've seen from the field.
Another possible source of this problem (in 7.0.X) is BufferReplace..?
Vadim
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Thomas Lockhart | 2001-03-21 01:25:17 | Re: Final Call: RC1 about to go out the door ... |
| Previous Message | Thomas Lockhart | 2001-03-21 01:20:21 | Re: Final Call: RC1 about to go out the door ... |