Re: Server instrumentation for 8.1

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

Responses

Browse pgsql-hackers by date

  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