Tom Lane wrote:
> I did a quick grep for PG_CATCH uses to see what we have along the lines
> of this bug:
> http://archives.postgresql.org/pgsql-hackers/2007-04/msg00218.php
>
> In current sources there are three places at risk:
>
> btbulkdelete, as noted in the above message
> pg_start_backup needs to reset forcePageWrites = false
> createdb wants to UnlockSharedObject and delete any already-copied files
>
> In createdb, the Unlock actually doesn't need to get cleaned up, since
> transaction abort would release the lock anyway. But leaving a possibly
> large mess of orphaned files doesn't seem nice.
>
> 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();
>
> where cancel_shmem_exit is defined to pop the latest shmem_exit_list
> entry if it matches the passed arguments (I don't see any particular
> need to search further than that in the list). This structure
> guarantees that cleanup_routine will be called on the way out of
> either a plain ERROR or a FATAL exit.
>
> Thoughts? We clearly must do something about this before we can even
> think of calling retail SIGTERM a supported feature ...
Here is a little different idea. Seems we want something more like:
PG_ON_EXIT();
{
cleanup_routine(arg);
}
> PG_TRY();
> {
> ... do something ...
> }
> PG_CATCH();
> {
> PG_RE_THROW();
> }
> PG_END_TRY();
PG_ON_EXIT() would place cleanup_routine() into the shmem_exit_list and
it would be called at the end of PG_CATCH and removed from
shmem_exit_list by PG_END_TRY(). Another idea would be to define the
PG_CATCH() first so it would be put in the shmem_exit_list before the
TRY was tried, but I assume you don't want all those functions to run on
exit.
--
Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
