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

Re: [HACKERS] Function to kill backend

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 (view raw or flat)
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

In response to

Responses

pgsql-patches by date

Next:From: Christopher Kings-LynneDate: 2004-07-26 14:42:53
Subject: Re: [HACKERS] Function to kill backend
Previous:From: Andreas PflugDate: 2004-07-26 14:02:55
Subject: Re: [HACKERS] Function to kill backend

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