From: | "Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> |
---|---|
To: | "ITAGAKI Takahiro" <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | <pgsql-patches(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: pgstattuple locking fix |
Date: | 2007-10-22 09:54:10 |
Message-ID: | 471C7342.2040102@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
ITAGAKI Takahiro wrote:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
>> ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
>>> Here is a trivial fix of locking issue in pgstattuple().
>> Hmm, is this really a bug, and if so how far back does it go?
>> I'm thinking that having a pin on the buffer should be enough to
>> call PageGetHeapFreeSpace.
>
> Hmm... we might use pd_upper and pd_lower at different times,
> but the error is ok for pgstattuple purpose.
> (It might be dangerous for tuple insertion, though.)
> Inconsistent usage of locks is confusable -- remove them, please.
No I think the original patch was right. You can indeed read
inconsistent values for pd_upper and pd_lower, though the window is very
small. But a bigger issue is that in 8.3 PageGetHeapFreeSpace counts the
used line pointers to see if MaxHeapTuplesPerPage has been reached, and
I'm not convinced you can do that safely without holding a lock.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2007-10-22 10:07:53 | Re: pgstattuple locking fix |
Previous Message | ITAGAKI Takahiro | 2007-10-22 09:42:44 | Re: pgstattuple locking fix |