Re: Add client connection check during the execution of the query - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Add client connection check during the execution of the query
Date
Msg-id CA+hUKGJEi-sZUELRqZg20GzS4cwStkKuVugK5DLvwqyh=Z2UuQ@mail.gmail.com
Whole thread Raw
In response to Re: Add client connection check during the execution of the query  (Andres Freund <andres@anarazel.de>)
Responses Re: Add client connection check during the execution of the query
List pgsql-hackers
On Sat, Dec 11, 2021 at 6:11 PM Andres Freund <andres@anarazel.de> wrote:
> Yuck. Is there really no better way to deal with this? What kind of errors is
> this trying to handle transparently? Afaics this still changes when we'd
> e.g. detect postmaster death.

The problem is that WaitEventSetWait() only reports the latch, if it's
set, so I removed it from the set (setting it to NULL), and then undo
that afterwards.  Perhaps we could fix that root problem instead.
That is, we could make it so that latches aren't higher priority in
that way, ie don't hide other events[1].  Then I wouldn't have to
modify the WES here, I could just ignore it in the output event list
(and make sure that's big enough for all possible events, as I had it
in the last version).  I'll think about that.

> Am I misunderstanding code or comment, or is the comment saying that it's ok
> to clobber the wes, but then we actually unclobber it?

It's explaining that it's OK to clobber the *socket*, but that the
*latch* needs to be unclobbered.

[1]  As described in WaitEventSetWait():

         * Check if the latch is set already. If so, leave the loop
         * immediately, avoid blocking again. We don't attempt to report any
         * other events that might also be satisfied.



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: parallel vacuum comments
Next
From: Amit Kapila
Date:
Subject: Re: Skipping logical replication transactions on subscriber side