Re: Add client connection check during the execution of the query

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: Add client connection check during the execution of the query
Дата
Msg-id CA+hUKGJEi-sZUELRqZg20GzS4cwStkKuVugK5DLvwqyh=Z2UuQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Add client connection check during the execution of the query  (Andres Freund <andres@anarazel.de>)
Ответы Re: Add client connection check during the execution of the query  (Thomas Munro <thomas.munro@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: parallel vacuum comments
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: Skipping logical replication transactions on subscriber side