Re: pg_terminate_backend() issues

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 ...
        regards, tom lane