Re: Dynamically sizing FSM? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Dynamically sizing FSM?
Date
Msg-id 27709.1168405713@sss.pgh.pa.us
Whole thread Raw
In response to Re: Dynamically sizing FSM?  (ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp>)
Responses Re: Dynamically sizing FSM?
List pgsql-hackers
ITAGAKI Takahiro <itagaki.takahiro@oss.ntt.co.jp> writes:
> Tom Lane <tgl@sss.pgh.pa.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


pgsql-hackers by date:

Previous
From: ITAGAKI Takahiro
Date:
Subject: Re: Dynamically sizing FSM?
Next
From: Tom Lane
Date:
Subject: Re: [PATCHES] Building libpq/psql with Borland BCC5