From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Magnus Hagander <mha(at)sollentuna(dot)net>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Function to kill backend |
Date: | 2004-04-06 19:23:21 |
Message-ID: | 526.1081279401@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> So I would vote for Yes on SIGINT by XID, but No on SIGTERM by PID, if Tom
> thinks there will be any significant support & troubleshooting involved for
> the latter.
Quite honestly, I don't know. We know that some people have done manual
SIGTERMs and not been burnt; and I'm not aware of any reason why it
wouldn't work; but I don't think it's well enough tested to be sure that
it will work. The sort of problem that I fear could arise is analogous
to the problem with kill -9'ing the postmaster: sure, the process is
gone and the database on disk is okay, but there might be resource leaks
or other problems left behind in shared memory. We would not see such
problems in normal use because SIGTERM is associated with complete
database shutdown and release of shared memory. With retail SIGTERM and
leaving the database up, though, it's a whole new ballgame and the
cleanup requirements become much stricter.
So like I say, I'm hesitant to buy into supporting this without a fairly
convincing argument that it's really needed.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Chris Browne | 2004-04-06 19:34:08 | The Tomb of the Unknown Type? |
Previous Message | Josh Berkus | 2004-04-06 19:10:10 | Re: Function to kill backend |