Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Basically, you can't make any critical changes to a shared buffer
>> if you haven't got exclusive lock on it. But that's exactly what
>> this patch is assuming it can do.
> It seems to me that the only possible way to close this hole is to
> acquire an exclusive lock before calling FlushBuffers, not shared.
> This lock would be held until the flag has been examined and reset; the
> actual WAL record and write would continue with a shared lock, as now.
Well, if we adopt the double buffering approach then the ex-lock would
only need to be held for long enough to copy the page contents to local
memory. So maybe this would be acceptable. It would certainly be a
heck of a lot simpler than any workable variant of the current patch
is likely to be; and we could simplify some existing code too (no more
need for the BM_JUST_DIRTIED flag for instance).
> (The alternative seems to be to abandon this idea for hint bit logging;
> we'll need something else.)
I'm feeling dissatisfied too --- seems like we're one idea short of a
good solution.
In the larger scheme of things, this patch shouldn't go in anyway as
long as there is some chance that we could have upgrade-in-place for
8.4 at the price of not increasing the page header size. So I think
there's time to keep thinking about it.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
