Re: pg_terminate_backend() issues

"Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

> ISTM that there will be more cases like this in future, so we need a
> general solution anyway. I propose the following sort of code structure
> for these situations:
>
> on_shmem_exit(cleanup_routine, arg);
> PG_TRY();
> {
> ... do something ...
> cancel_shmem_exit(cleanup_routine, arg);
> }
> PG_CATCH();
> {
> cancel_shmem_exit(cleanup_routine, arg);
> cleanup_routine(arg);
> PG_RE_THROW();
> }
> PG_END_TRY();

[We would also have to block SIGTERM around the second cancel_shmem_exit and
cleanup_routine, no? Or if it's idempotent (actually, wouldn't it have to be?)
run them in the reverse order.]

This seems exceptionally fragile. Someone's bound to add another case without
realizing it. I thought about doing something like having a flag
in_unprotected_pg_try which PG_TRY would set to true, and on_shmem_exit would
clear. Then any LWLock or other shmem operation could assert it's cleared.

But that doesn't work for nested PG_TRY blocks. Possibly we could get it to
work by keeping a pair of counters but I'm not sure that's sufficient.

Are all the known cases LWLocks? Is there a reason we couldn't just have a
generic cleanup routine which just releases all LWLocks we hold before
exiting?

Or weakly -- an assert in CHECK_FOR_INTERRUPTS that there are no LWLocks held
or if there are that there's a cleanup routine in place. We wouldn't know for
sure that it's the *right* cleanup routine or enough cleanup routines but
hopefully we would catch the error often enough to notice.

--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's 24x7 Postgres support!