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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 1998-10-02 03:44:54 | delete from ..;vacuum crashes |
Previous Message | Bruce Momjian | 1998-10-02 02:24:20 | Re: [HACKERS] It sorta works, but I'm confused about locking |