Re: Improve the granularity of PQsocketPoll's timeout parameter?

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Improve the granularity of PQsocketPoll's timeout parameter?
Дата
Msg-id 9642de7b315640ece27fe7cb72a9d90dec707813.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Improve the granularity of PQsocketPoll's timeout parameter?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Improve the granularity of PQsocketPoll's timeout parameter?
Список pgsql-hackers
On Mon, 2024-06-10 at 19:57 -0400, Tom Lane wrote:
> Because a common call pattern is to loop around PQsocketPoll calls.
> In that scenario you generally want to nail down the timeout time
> before starting the loop, not have it silently move forward after
> any random event that breaks the current wait (EINTR for example).
> pqSocketCheck and pqConnectDBComplete both rely on this.

I agree it makes things easier for a caller following that pattern,
because it doesn't need to recalculate the timeout each time through
the loop.

But:

1. If your clock goes backwards, you can end up waiting for an
arbitrarily long time. To prevent that you need to do some
recalculation each time through the loop anyway.

2. Inventing a new absolute time type just for this single purpose
seems strange to me. Would it be useful in other places? Are we going
to define what kinds of operations/transformations are supported?

3. I can't recall another API that uses absolute time for a timeout;
are you aware of a precedent?

Regards,
    Jeff Davis




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amul Sul
Дата:
Сообщение: Re: Logical Replication of sequences
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: race condition in pg_class