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

Re: [HACKERS] Proper cleanup at backend exit

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <maillist(at)candle(dot)pha(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: [HACKERS] Proper cleanup at backend exit
Date: 1998-10-02 00:29:17
Message-ID: 29241.907288157@sss.pgh.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...

> 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.

			regards, tom lane

Responses

pgsql-hackers by date

Next:From: Vadim MikheevDate: 1998-10-02 01:20:25
Subject: Re: [HACKERS] It sorta works, but I'm confused about locking
Previous:From: Tom LaneDate: 1998-10-02 00:25:15
Subject: Re: [HACKERS] It sorta works, but I'm confused about locking

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