From: | "Magnus Hagander" <mha(at)sollentuna(dot)net> |
---|---|
To: | "Alvaro Herrera" <alvherre(at)surnet(dot)cl> |
Cc: | "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 13:15:00 |
Message-ID: | 6BCB9D8A16AC4241919521715F4D8BCE6C7497@algol.sollentuna.se |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2005-05-12 13:40:40 | Re: [HACKERS] plperl and pltcl installcheck targets |
Previous Message | Alvaro Herrera | 2005-05-12 13:12:48 | Re: Server instrumentation for 8.1 |