From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jim Nasby <jim(at)nasby(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: WALInsertLock contention |
Date: | 2011-06-09 16:37:55 |
Message-ID: | BANLkTi=V-8EZwTuXx7T28=yfkjrq9_KRAw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jun 8, 2011 at 11:30 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> The heap pages that have been marked this way may or may not have to
> be off limits from the backend other than the one that did the
> marking, and if they have to be off limits logically, there may be no
> realistic path to make them so.
After some more thought, plus a bit of off-list coaching from Haas, I
see now the whole approach is basically a non-starter due to the
above. Heap pages *are* off limits, because once deferred they can't
be scribbled on and committed by other transactions -- that would
violate the 'wal before data' rule. To make it 'work', you'd have to
implement shared memory machinery to do cooperative flushing as
suggested upthread (complex, nasty) or simply block on deferred
pages...which would be a deadlock factory.
Oh well. :(
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Kohei KaiGai | 2011-06-09 16:39:26 | Re: [v9.1] sepgsql - userspace access vector cache |
Previous Message | Stephen Frost | 2011-06-09 16:37:22 | Re: [v9.1] sepgsql - userspace access vector cache |