| From: | Bruce Momjian <bruce(at)momjian(dot)us> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, pgsql-hackers(at)postgresql(dot)org | 
| Subject: | Re: pg_terminate_backend() issues | 
| Date: | 2008-04-15 23:30:22 | 
| Message-ID: | 200804152330.m3FNUMU22039@momjian.us | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers | 
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  <bruce(at)momjian(dot)us>        http://momjian.us
  EnterpriseDB                             http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-04-15 23:47:25 | Re: pg_terminate_backend() issues | 
| Previous Message | Gregory Stark | 2008-04-15 23:08:01 | Re: pg_terminate_backend() idea | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-04-15 23:47:25 | Re: pg_terminate_backend() issues | 
| Previous Message | Gregory Stark | 2008-04-15 23:08:01 | Re: pg_terminate_backend() idea |