Re: what about _PG_fini
От | Cédric Villemain |
---|---|
Тема | Re: what about _PG_fini |
Дата | |
Msg-id | e94e14cd0912231343g51032a41ne1705a35bd4d588d@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: what about _PG_fini (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: