Re: Autovacuum worker doesn't immediately exit on postmaster death

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Autovacuum worker doesn't immediately exit on postmaster death
Дата
Msg-id 40062.1604008069@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Autovacuum worker doesn't immediately exit on postmaster death  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Ответы Re: Autovacuum worker doesn't immediately exit on postmaster death  (Stephen Frost <sfrost@snowman.net>)
Re: Autovacuum worker doesn't immediately exit on postmaster death  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
> On 2020-Oct-29, Stephen Frost wrote:
>> I do think it'd be good to find a way to check every once in a while
>> even when we aren't going to delay though.  Not sure what the best
>> answer there is.

> Maybe instead of thinking specifically in terms of vacuum, we could
> count buffer accesses (read from kernel) and check the latch once every
> 1000th such, or something like that.  Then a very long query doesn't
> have to wait until it's run to completion.  The cost is one integer
> addition per syscall, which should be bearable.

I'm kind of unwilling to add any syscalls at all to normal execution
code paths for this purpose.  People shouldn't be sig-kill'ing the
postmaster, or if they do, cleaning up the mess is their responsibility.
I'd also suggest that adding nearly-untestable code paths for this
purpose is a fine way to add bugs we'll never catch.

The if-we're-going-to-delay-anyway path in vacuum_delay_point seems
OK to add a touch more overhead to, though.

            regards, tom lane



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

Предыдущее
От: Thomas Munro
Дата:
Сообщение: -Wformat-signedness
Следующее
От: Victor Yegorov
Дата:
Сообщение: Re: Deleting older versions in unique indexes to avoid page splits