Re: Dynamically sizing FSM?

ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm of the opinion that the solution to FSM being fixed-size is to keep
>> it somewhere else, ie, on disk (possibly with some sort of cache in
>> shared memory for currently-used entries).

> What do you think dynamic allocation from shared_buffers? ie, remove
> a buffer page in the shared buffer pool and use the 8kB of memory
> for another purpose.

The problem with that is that (a) it creates more contention load on the
shared buffer pool's management structures, and (b) if the chosen buffer
is dirty then you have a different subsystem trying to do buffer I/O,
which is at best a modularity bug and at worst a correctness or deadlock
problem.

We use separate buffer areas for xlog, clog, subtrans, etc than for the
main buffer arena. I think it's a good idea to keep that approach for
any buffer space created for FSM. It might represent a slightly
inefficient use of the shared memory as a whole, but it helps preserve
the developers' sanity ;-)

regards, tom lane