Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] Proper cleanup at backend exit

From: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
To: tgl(at)sss(dot)pgh(dot)pa(dot)us (Tom Lane)
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Proper cleanup at backend exit
Date: 1998-10-02 02:25:23
Message-ID: 199810020225.WAA23362@candle.pha.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
> Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us> writes:
> >> [ should we work harder to ensure pg_listener entries get cleaned out? ]
> 
> > Seems like we should try and clean them out, especially when the backend
> > is doing a normal exit.  In a panic exit, we don't need to clean it out.
> 
> OK, I will add some more code to try to cope with the exit-during-
> uncommitted-transaction case.
> 
> > We can install something into proc_exit() and shmem_exit() to clean out
> > the table.
> 
> The old code inserted the cleanup action into shmem_exit().  Is that the
> right list to put it in?  I'm not clear on the difference between
> shmem_exit and proc_exit lists...

proc_exit is triggered on every backend exit.  shmem_exit is for
postmaster exit, or postmaster shared memory reset.

> 
> > You can have a global variable that installed the pg_listen
> > cleaner the first time a notify() is done so as not to install a new
> > exit handler for each notify() call.
> 
> That part's already done.

Cool.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist(at)candle(dot)pha(dot)pa(dot)us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026


In response to

pgsql-hackers by date

Next:From: Tatsuo IshiiDate: 1998-10-02 03:44:54
Subject: delete from ..;vacuum crashes
Previous:From: Bruce MomjianDate: 1998-10-02 02:24:20
Subject: Re: [HACKERS] It sorta works, but I'm confused about locking

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group