From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: zombie connections |
Date: | 2020-04-03 13:57:18 |
Message-ID: | CA+TgmoZPV+jP3+CceKtAmjgR4j1Q2JLT2=n1R1irBfcVWJWCMg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Apr 3, 2020 at 9:52 AM Isaac Morland <isaac(dot)morland(at)gmail(dot)com> wrote:
> Does it make any difference if the query is making changes? If the query is just computing a result and returning it to the client, there is no point in continuing once the socket is closed. But if it is updating data or making DDL changes, then at least some of the time it would be preferable for the changes to be made. Having said that, in normal operation one wants, at the client end, to see the message from the server that the changes have been completed, not just fire off a change and hope it completes.
The system can't know whether the query is going to change anything,
because even if the query is a SELECT, it doesn't know whether any of
the functions or operators called from that SELECT might write data.
I don't think it would be smart to make behavior like this depend on
whether the statement is a SELECT vs. INSERT/UPDATE/DELETE, or on
things like whether there is an explicit transaction open. I think we
should just have a feature that kills the server process if the
connection goes away. If some people don't want that, it can be
optional.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2020-04-03 14:00:47 | Re: zombie connections |
Previous Message | Isaac Morland | 2020-04-03 13:52:22 | Re: zombie connections |