Re: Server instrumentation for 8.1 - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: Server instrumentation for 8.1
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCE6C7497@algol.sollentuna.se
Whole thread Raw
In response to Server instrumentation for 8.1  (Andreas Pflug <pgadmin@pse-consulting.de>)
Responses Re: Server instrumentation for 8.1  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
> > Not kill -9. Kill -9 is "safe" because it causes a complete
> restart of
> > the postmaster (it's the same as a backend crash, really).
> Kill -INT
> > is also safe, because it does a simlpe query cancel.
>
> Hmm, would it be possible to use another signal for "cancel
> the current query and enter a state where no queries are
> accepted"?  That would mean driving the backend to a known
> idle state, allowing further action to end the connection.
> From the client perspective, the connection is no longer
> useful anyway, so he can only disconnect.

AFAIK, there are no signals left to use...

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. But it comes down to
the fact that we're out of signals.

//Magnus


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Server instrumentation for 8.1
Next
From: Tom Lane
Date:
Subject: Re: implementing NOTIFY with message parameter