Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size
Дата
Msg-id 20220617180247.m62yfxy4d4pq4xvl@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: PG 15 (and to a smaller degree 14) regression due to ExprEvalStep size  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Hi,

On 2022-06-17 13:43:49 -0400, Tom Lane wrote:
> Andres Freund <andres@anarazel.de> writes:
> > I should have been more precise - what I meant was a timeout.c API that allows
> > the caller to pass in "now", which in this case we'd get from
> > GetCurrentTransactionStopTimestamp(), which would avoid the additional
> > timestamp computation.
> 
> I don't care for that one bit: it makes the accuracy of all timeouts
> dependent on how careful that caller is to provide an up-to-date "now".

I don't think it'd necessarily have to influence the accuracy of all timeouts
- but I've not looked at timeout.c much before. From what I understand we use
'now' for two things: First, to set ->start_time in enable_timeout() and
second to schedule the alarm in schedule_alarm(). An inaccurate start_time
won't cause problems for other timers afaics and it looks to me that it
wouldn't be too hard to only require an accurate 'now' if the new timeout is
nearest_timeout and now + nearest_timeout < signal_due_at?

It's probably to complicated to tinker with now tho.

Greetings,

Andres Freund



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

Предыдущее
От: Josh Soref
Дата:
Сообщение: Re: SGML doc file references
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Using PQexecQuery in pipeline mode produces unexpected Close messages