Re: pg_terminate_backend() issues

"Tom Lane" <tgl@sss.pgh.pa.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!