Re: shmem startup and shutdown hooks

Hi,

While going through Andres' BDR code I noticed that it has a shmem
startup hook, which installs a on_shmem_exit() callback to write stuff
at shutdown time. This works fine but seems somewhat of a hazard: it is
having postmaster do the actual write, which has to access shared memory
while doing it. Moreover, since the callback is installed to be called
at shmem reset, it means that a process crash causes this code to be
called, which seems similarly broken.

It seems that the right place to do this is checkpointer shutdown, i.e.
when checkpointer is told to close shop it should also invoke various
modules' shutdown callbacks. There's no hook point there though, so
we'd need to introduce something new for this specific purpose.

We already have pg_stat_statements doing this, viz. pgss_shmem_startup():

/*
* If we're in the postmaster (or a standalone backend...), set up a shmem
* exit hook to dump the statistics to disk.
*/
if (!IsUnderPostmaster)
on_shmem_exit(pgss_shmem_shutdown, (Datum) 0);

Also, it'd be good to discuss what should happen when another process
crashes. Should we attempt to write the data anyway, or should we reset
it just like we do for pgstats?

Thoughts?

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On Saturday, May 25, 2013 12:50 AM Alvaro Herrera wrote:

> Hi,

> While going through Andres' BDR code I noticed that it has a shmem
> startup hook, which installs a on_shmem_exit() callback to write stuff
> at shutdown time. This works fine but seems somewhat of a hazard: it is
> having postmaster do the actual write, which has to access shared memory
> while doing it. Moreover, since the callback is installed to be called
> at shmem reset, it means that a process crash causes this code to be
> called, which seems similarly broken.

> It seems that the right place to do this is checkpointer shutdown, i.e.
> when checkpointer is told to close shop it should also invoke various
> modules' shutdown callbacks. There's no hook point there though, so
> we'd need to introduce something new for this specific purpose.

Do you mean to say that during shutdown of checkpoint, it should call interface which does same
as shmem_exit() which means call shutdown callbacks of other modules?
Why would checkpointer shutdown is better place to handle?

With Regards,
Amit Kapila.

Amit kapila wrote:
>
> On Saturday, May 25, 2013 12:50 AM Alvaro Herrera wrote:

> > It seems that the right place to do this is checkpointer shutdown, i.e.
> > when checkpointer is told to close shop it should also invoke various
> > modules' shutdown callbacks. There's no hook point there though, so
> > we'd need to introduce something new for this specific purpose.
>
> Do you mean to say that during shutdown of checkpoint, it should call
> interface which does same as shmem_exit() which means call shutdown
> callbacks of other modules?

I mean we should have some other hooking point for modules, one which is
guaranteed to be called only during shutdown. The current hook point in
use is shared memory reset, which does happen during shutdown; but also
happens when a process crashes and postmaster reinits the whole thing.

> Why would checkpointer shutdown is better place to handle?

Because it's the process whose termination defines when a system
shutdown takes place.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services