Re: what about _PG_fini - Mailing list pgsql-hackers

From Cédric Villemain
Subject Re: what about _PG_fini
Date
Msg-id e94e14cd0912231343g51032a41ne1705a35bd4d588d@mail.gmail.com
Whole thread Raw
In response to Re: what about _PG_fini  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
2009/12/23 Tom Lane <tgl@sss.pgh.pa.us>:
> Cédric Villemain <cedric.villemain.debian@gmail.com> writes:
>> I wonder what is the future of "_PG_fini", documentation say at [1]:
>> "Note that _PG_fini will only be called during an unload of the file,
>> not during process termination. (Presently, unloads are disabled and
>> will never occur, but this may change in the future.)"
>
> What we'd need to work out before (re)enabling _PG_fini is some
> consistent rules for allowing multiple modules to get into *and out of*
> the same hook pointers.  The current coding methods are very
> load-order-dependent, and that would have to be fixed somehow.

Ok,  thank you for clarification.

>
>> 1. do we want a _PG_fini which is call on server stop ?
>> 2. what's actually the best way to execute some code when server stop,
>> if one have ideas ... ?
>
> In any case, _PG_fini would have approximately nothing to do with "code
> to be executed on server stop".  It would happen at session end,
> typically.
>
> Personally I'd suggest putting whatever you have in mind into your
> service start/stop scripts.

Yes, I thought it was probably the simplest way to do it.

for information I have some functions to make a snapshot of the blocks
which are in buffer cache (it is a max of 32KB per segment) and to
reload them when server start. Option to execute them without
'external' code could have been fine.

>
>                        regards, tom lane
>


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Removing pg_migrator limitations
Next
From: Jeff Davis
Date:
Subject: Re: About the CREATE TABLE LIKE indexes vs constraints issue