Re: Shared memory and memory context question - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Shared memory and memory context question
Date
Msg-id 10919.1139156199@sss.pgh.pa.us
Whole thread Raw
In response to Re: Shared memory and memory context question  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Shared memory and memory context question
List pgsql-hackers
Martijn van Oosterhout <kleptog@svana.org> writes:
> So what you load are the already processed rules? In that case you
> could probably use the buffer management system. Ask it to load the
> blocks and they'll be in the buffer cache. As long as you have the
> buffer pinned they'll stay there.

... until you get to the end of the transaction, where the buffer
manager will barf because somebody forgot an unpin.  Long-term buffer
pins are really not acceptable anyway --- you'd essentially be asserting
that your little facility is more important than any other use of shared
buffers, and I'm sorry but that ain't so.

AFAICT the data structures you are worried about don't have any readily
predictable size, which means there is no good way to keep them in
shared memory --- we can't dynamically resize shared memory.  So I think
storing the rules in a table and loading into private memory at need is
really the only reasonable solution.  Storing them in a table has a lot
of other advantages anyway, mainly that you can manipulate them from
SQL.

You can find some prior discussion of similar issues in the archives;
IIRC the idea of a shared plan cache was being kicked around for awhile
some years back.
        regards, tom lane


pgsql-hackers by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: [ADMIN] Postgres 8.1.x and MIT Kerberos 5
Next
From: "hassane ariouat"
Date:
Subject: renseignement