| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andreas Pflug <pgadmin(at)pse-consulting(dot)de> |
| Cc: | Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, Magnus Hagander <mha(at)sollentuna(dot)net>, Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-patches <pgsql-patches(at)postgresql(dot)org> |
| Subject: | Re: [HACKERS] Function to kill backend |
| Date: | 2004-07-26 14:21:19 |
| Message-ID: | 27081.1090851679@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-patches |
Andreas Pflug <pgadmin(at)pse-consulting(dot)de> writes:
> Taken from your mail, I understand that a killed backend might leave
> some loose ends, eg. open locks, which would degrade the cluster's
> performance. Still, it should not corrupt the shared mem, just leave it
> as if the backend's still alive and sleeping, right?
Well, I was citing that as an example of the sort of trouble that is
foreseeable; I don't say either that it would happen, or that it's the
only bad thing that could happen. But having backends block on locks
that will never be released sure seems like something that would look
like database corruption to the average DBA.
If you want to put in the function and document that it may cause
problems, I won't object; it's not like we don't have other features
that are poorly implemented :-(. But my vote would be to remove it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christopher Kings-Lynne | 2004-07-26 14:42:53 | Re: [HACKERS] Function to kill backend |
| Previous Message | Andreas Pflug | 2004-07-26 14:02:55 | Re: [HACKERS] Function to kill backend |