Re: elog(FATAL) vs shared memory

"Heikki Linnakangas" <heikki(at)enterprisedb(dot)com> writes:

> Tom Lane wrote:
>
>> AFAICS, there are basically two ways we might try to approach this:
>>
>> Plan A: establish the rule that you mustn't try to clean up shared
>> memory state in a PG_CATCH block. Anything you need to do like that
>> has to be handled by an on_shmem_exit hook function, so it will be
>> called during a FATAL exit. (Or maybe you can do it in PG_CATCH for
>> normal ERROR cases, but you need a backing on_shmem_exit hook to
>> clean up for FATAL.)
>>...
>> So Plan B seems unacceptably fragile. Does anyone see a way to fix it,
>> or perhaps a Plan C with a totally different idea? Plan A seems pretty
>> ugly but it's the best I can come up with.
>
> Yeah, plan A seems like the way to go.

The alternative is that instead of a general purpose shmem hook you note the
pid of the process that is expecting to handle the cleanup. So for instance
something like pg_start_backup instead of setting a flag would store its pid.
Then someone else who comes along and finds the field set has to double check
if the pid is actually still around and if not it has to clean it up itself.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com