Re: Server instrumentation for 8.1

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Magnus Hagander" <mha(at)sollentuna(dot)net>
Cc: "Alvaro Herrera" <alvherre(at)surnet(dot)cl>, "Andreas Pflug" <pgadmin(at)pse-consulting(dot)de>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Server instrumentation for 8.1
Date: 2005-05-12 14:39:14
Message-ID: 511.1115908754@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> Another thought I had along that line was use a different signal to
> simply do a "query cancel" and set a global flag that is more or less
> "get out when you're done with query cancel". Then if that flag is set,
> just close the connection and proceed as if the client dropped the
> connection - that has to be a well tested codepath.

This is pretty much exactly what kill -TERM does today, and the point is
that the code path has only been extensively tested in the context of
database-wide shutdown. No one can honestly say that they are sure
there are no resource leaks, locks left unreleased, stuff like that.
That kind of problem wouldn't be visible after a shutdown, but it will
become visible if backends are killed individually with -TERM.

Now in theory there are no bugs and this'll work fine. What disturbs me
is the lack of testing by anyone who knows what to look for ...

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Marc G. Fournier 2005-05-12 14:46:38 Re: New Contrib Build?
Previous Message Tom Lane 2005-05-12 14:33:43 Re: SQL_ASCII vs. 7-bit ASCII encodings