On 2021-Aug-23, Robert Haas wrote:
> On Mon, Aug 23, 2021 at 10:45 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> > Do we actually need new GUCs, though? I think we should never let an
> > unresponsive client dictate what the server does, because that opens the
> > door for uncooperative or malicious clients to wreak serious havoc. I
> > think the implementation should wait until time now+X to cancel the
> > query, but if by time now+2X (or whatever we deem reasonable -- maybe
> > now+1.1X) we're still waiting, then it's okay to just close the
> > connection. This suggests a completely different implementation, though.
>
> I don't quite understand what you mean by waiting until time now+X to
> cancel the query. We don't know a priori when query cancels are going
> to happen, but when they do happen we want to respond to them as
> quickly as we can. It seems reasonable to say that if we can't handle
> them within X amount of time we can resort to emergency measures, but
> that's basically what the patch does, except it uses a GUC instead of
> hardcoding X.
Aren't we talking about query cancellations that occur in response to a
standby delay limit? Those aren't in response to user action. What I
mean is that if the standby delay limit is exceeded, then we send a
query cancel; we expect the standby to cancel its query at that time and
then the primary can move on. But if the standby doesn't react, then we
can have it terminate its connection. I'm looking at the problem from
the primary's point of view rather than the standby's point of view.
--
Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/