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. I'm wary of this "solution" because it's likely to reduce concurrency tremendously ... thoughts? (The alternative seems to be to abandon this idea for hint bit logging; we'll need something else.) -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
