From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Andres Freund <andres(at)anarazel(dot)de>, Victor Yegorov <vyegorov(at)gmail(dot)com>, Alexander Kukushkin <cyberdemn(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Autovacuum worker doesn't immediately exit on postmaster death |
Date: | 2020-10-29 21:47:49 |
Message-ID: | 40062.1604008069@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Victor Yegorov | 2020-10-29 22:05:28 | Re: Deleting older versions in unique indexes to avoid page splits |
Previous Message | Thomas Munro | 2020-10-29 21:37:07 | -Wformat-signedness |