Re: client_connection_check_interval default value

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Jeremy Schneider <schneider(at)ardentperf(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Marat Buharov <marat(dot)buharov(at)gmail(dot)com>, Greg Sabino Mullane <htamfids(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>
Subject: Re: client_connection_check_interval default value
Date: 2026-02-06 00:18:50
Message-ID: CAOYmi+=UXHJ2mmY3SXPFAV-79QcSCxM-4015te4Ka-5L_ewsow@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Feb 5, 2026 at 4:01 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I think enabling it by default is a nonstarter, because it changes
> behavior in a significant way. Specifically, it's always been the
> case that if the client disconnects during a non-SELECT query (or
> anything that doesn't produce output), the backend would complete that
> query before ending the session.

Ha, I hadn't even thought about the possibility of fire-and-forget...

> I think it's very likely that there
> are users depending on that behavior.

From a quick search, yeah, probably:

https://dba.stackexchange.com/questions/247206/will-query-continue-to-run-even-after-network-times-out

--Jacob

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-02-06 00:58:28 Re: pg_upgrade: optimize replication slot caught-up check
Previous Message Tom Lane 2026-02-06 00:13:09 Re: Unfortunate pushing down of expressions below sort