"Tom Lane" <[EMAIL PROTECTED]> 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!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
