Обсуждение: Fwd: Questions about connection clean-up and "invalid page header"

Given this thread on pgsql-general I wonder if we should have
something like 1 in every 1,000 CHECK_FOR_INTERRUPTS check if the
client socket is still open.

This has come up in the past and the concern was that syscalls would
be way too slow to put in critical loops but perhaps if it's only done
once every n checks it would be possible to find a good tradeoff?


---------- Forwarded message ----------
From: Greg Stark <gsstark@mit.edu>
Date: Mon, Jan 25, 2010 at 1:52 PM
Subject: Re: Questions about connection clean-up and "invalid page header"
To: Herouth Maoz <herouth@unicell.co.il>
Cc: Scott Marlowe <scott.marlowe@gmail.com>, pgsql-general@postgresql.org


On Mon, Jan 25, 2010 at 1:16 PM, Herouth Maoz <herouth@unicell.co.il> wrote:
> Well, I assume by the fact that eventually I get an "Unexpected end of file"
> message for those queries, that something does go in and check them. Do you
> have any suggestion as to how to cause the postgresql server to do so
> earlier?

No, Postgres pretty intentionally doesn't check because checking would
be quite slow.

If this is a plpgsql function looping you can put a RAISE NOTICE in
the loop periodically. I suppose you could write such a function and
add it to your query but whether it does what you want will depend on
the query plan.

--
greg



-- 
greg

Greg Stark <gsstark@mit.edu> writes:
> Given this thread on pgsql-general I wonder if we should have
> something like 1 in every 1,000 CHECK_FOR_INTERRUPTS check if the
> client socket is still open.

... and do what?  If so, why?
        regards, tom lane

On Mon, Jan 25, 2010 at 6:31 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Greg Stark <gsstark@mit.edu> writes:
>> Given this thread on pgsql-general I wonder if we should have
>> something like 1 in every 1,000 CHECK_FOR_INTERRUPTS check if the
>> client socket is still open.
>
> ... and do what?  If so, why?

Hm, an interesting question.

Any time the client closes the server->client connection the server
_could_ abort the transaction and the client would be none-the-wiser.
Since it isn't sticking around to see if the transaction commits then
for all it knows the server is already aborting some of the
connections. At least in cases where it's running a SELECT then no
useful work is going to get done anyways since once the first results
are ready the server's only going to get a socket error and abort at
that point.

When the client closes the client->server connection I don't think
it's wise to take any action. Though I suppose if the connection is in
an explicit transaction and the operation currently running produces
no output (ie UPDATE or DELETE or INSERT) then an argument could be
made that no useful work could be done there either since the work
will only be rolled back.

--
greg