|From:||Stephen Frost <sfrost(at)snowman(dot)net>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, 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|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> 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.
Alright, for this part at least, seems like it'd be something like the
Only lightly tested, but does seem to address the specific example which
was brought up on this thread.
|Next Message||John Naylor||2020-12-10 19:29:07||Re: cutting down the TODO list thread|
|Previous Message||Bruce Momjian||2020-12-10 18:49:39||Re: Proposed patch for key managment|