On Fri, Apr 3, 2020 at 11:50 AM Tom Lane wrote:
> (2) It only wins if a statement timeout is active, otherwise it makes
> things worse, because then you need setitimer() at statement start
> and end just to enable/disable the socket check timeout. Whereas
> if you just let a once-a-minute timeout
Robert Haas writes:
> On Fri, Apr 3, 2020 at 10:34 AM Tom Lane wrote:
>> In general I think the threshold problem for a patch like this will be
>> "how do you keep the added overhead down". As Robert noted upthread,
>> timeout.c is quite a bit shy of being able to handle timeouts that
>> persist
On Fri, Apr 3, 2020 at 10:34 AM Tom Lane wrote:
> In general I think the threshold problem for a patch like this will be
> "how do you keep the added overhead down". As Robert noted upthread,
> timeout.c is quite a bit shy of being able to handle timeouts that
> persist across statements. I don'
Pavel Stehule writes:
> I prefer simple solution without any "intelligence". It is much safer to
> close connect and rollback. Then it is clean protocol - when server didn't
> reported successful end of operation, then operation was reverted - always.
It would be a fatal mistake to imagine that t
pá 3. 4. 2020 v 15:52 odesílatel Isaac Morland
napsal:
> On Fri, 3 Apr 2020 at 08:30, Robert Haas wrote:
>
>>
>> I don't have a terribly specific idea about how to improve this, but
>> is there some way that we could, at least periodically, check the
>> socket to see whether it's dead? Noticing
On Fri, Apr 3, 2020 at 9:52 AM Isaac Morland 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 cha
On Fri, 3 Apr 2020 at 08:30, Robert Haas wrote:
>
> I don't have a terribly specific idea about how to improve this, but
> is there some way that we could, at least periodically, check the
> socket to see whether it's dead? Noticing the demise of the client
> after a configurable interval (maybe
On Fri, Apr 3, 2020 at 9:34 AM Konstantin Knizhnik
wrote:
> There was a patch on commitfest addressing this problem:
> https://commitfest.postgresql.org/21/1882/
> It it currently included in PostgrePro EE, but the author of the patch
> is not working in our company any more.
> Should we resurrect
On 03.04.2020 15:29, Robert Haas wrote:
Hi,
Suppose that the server is executing a lengthy query, and the client
breaks the connection. The operating system will be aware that the
connection is no more, but PostgreSQL doesn't notice, because it's not
try to read from or write to the socket. I
On Fri, Apr 03, 2020 at 02:40:30PM +0200, Pavel Stehule wrote:
> pá 3. 4. 2020 v 14:30 odesílatel Robert Haas napsal:
> >
> > Suppose that the server is executing a lengthy query, and the client
> > breaks the connection. The operating system will be aware that the
> > connection is no more, but P
pá 3. 4. 2020 v 14:30 odesílatel Robert Haas napsal:
> Hi,
>
> Suppose that the server is executing a lengthy query, and the client
> breaks the connection. The operating system will be aware that the
> connection is no more, but PostgreSQL doesn't notice, because it's not
> try to read from or w
Hi,
Suppose that the server is executing a lengthy query, and the client
breaks the connection. The operating system will be aware that the
connection is no more, but PostgreSQL doesn't notice, because it's not
try to read from or write to the socket. It's not paying attention to
the socket at all
12 matches
Mail list logo
