"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> Alvaro Herrera <alvherre@commandprompt.com> writes:
>> Josh Berkus wrote:
>>> Ideally, of course, there would be no wal_buffers setting, and WAL
>>> buffers would be allocated from shared_buffers pool on demand...
>
>> Same for pg_subtrans, pg_clog, etc (as previously discussed)
>
> I agree with that for pg_clog and friends, but I'm much more leery of
> folding WAL into the same framework. Its access pattern is *totally*
> unlike standard caches, so the argument that this would be good for
> performance is resting on nothing but imagination. Also I'm concerned
> about possible deadlocks, because WAL is customarily accessed while
> holding one or more exclusive buffer locks.
Well it may still be worthwhile stealing buffers from shared_buffers even if
we set a special flag marking them as owned by WAL and out of bounds for
the normal buffer manager.
At least that way we could always steal more if we want or return some, as
long as we're careful about when we do it. That would open the door to having
these parameters be dynamically adjustable. That alone would be worthwhile
even if we bypass all bells and whistles of the buffer manager.
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services!
