dynamic loading of .so

TJ O'Donnell <tjo@acm.org> writes:

I have begun to use some static variables in my c-language
functions to maintain state (3rd party licensing issues) during
the course of a session (postgres process, spawned by postmaster).
These are declared static outside the scope of any function.
(is global the correct term anymore?)
When I use dynamic loading of my .so,
each session is independent, with its own static variables.
Will the same be true if I were to load the .so once when
the database starts up? Or will there be just one set of
static variables for all sessions?

Each backend process has its own memory space, so the variables will
still be independent.

-Doug

are there any way to make them global for all the instances?

On 10/14/2005, "Douglas McNaught" <doug@mcnaught.org> wrote:

<cristian@clickdiario.com> writes:

are there any way to make them global for all the instances?

Put them in shared memory. This probably isn't trival, as all the
shared memory is allocated up front and used for existing purposes (at
least, as I understand it).

I guess you could always allocate your own shmem segment, but managing
it (and making sure it goes away when the backend exits) would be a
pain.

-Doug

Douglas McNaught <doug@mcnaught.org> writes:

<cristian@clickdiario.com> writes:

are there any way to make them global for all the instances?

Put them in shared memory. This probably isn't trival, as all the
shared memory is allocated up front and used for existing purposes (at
least, as I understand it).

There's a "slop factor" of 100KB or so in the shared memory size
calculation, which means that an add-on library that requests space soon
enough could probably get away with allocating up to a few KB without
causing any problems. (The slop is not totally useless, since for
instance the lock manager might eat it up if more locks get requested
than expected.)

In the long run it might be interesting to add hooks that allow
preloaded libraries to contribute to the shmem sizing calculation and
then to snarf up the space they've requested before it can get eaten by
the lockmgr.

regards, tom lane

You are talking about a shmem block using by the backend, right? Or about my
"own" shmem block?. I'm very interested in the implementation of a
"constants" like functionality to pgsql, but I don't know where to start
with... Any help or ideas?

-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Domingo, 16 de Octubre de 2005 10:42 p.m.
To: Douglas McNaught
Cc: cristian@clickdiario.com; tjo@acm.org; pgsql-general@postgresql.org
Subject: Re: [GENERAL] dynamic loading of .so

Douglas McNaught <doug@mcnaught.org> writes:

<cristian@clickdiario.com> writes:

are there any way to make them global for all the instances?

Put them in shared memory. This probably isn't trival, as all the
shared memory is allocated up front and used for existing purposes (at
least, as I understand it).

There's a "slop factor" of 100KB or so in the shared memory size
calculation, which means that an add-on library that requests space soon
enough could probably get away with allocating up to a few KB without
causing any problems. (The slop is not totally useless, since for
instance the lock manager might eat it up if more locks get requested
than expected.)

In the long run it might be interesting to add hooks that allow
preloaded libraries to contribute to the shmem sizing calculation and
then to snarf up the space they've requested before it can get eaten by
the lockmgr.

regards, tom lane

If you need user-accessible shared variables, you could take a look at
how Veil http://pgfoundry.org/projects/veil/ achieves this.

Veil provides a limited number of shared variables with an API for SQL
access. The variables may only be set during initialisation or reset to
avoid system state changing part-way through a transaction. Veil goes
to considerable trouble to deal with this. If this is not a concern for
you, you may be able to do something simpler but you would have to
perform extra locking on assignment.

Feel free to take whatever you can from Veil.

__
Marc