Re: Autovacuum worker doesn't immediately exit on postmaster death - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Autovacuum worker doesn't immediately exit on postmaster death
Date
Msg-id CA+TgmobzFa1LOcGJo2nzr8mdZJCj=GndtcJZn9t4hhQ3YPr24A@mail.gmail.com
Whole thread Raw
In response to Re: Autovacuum worker doesn't immediately exit on postmaster death  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: Autovacuum worker doesn't immediately exit on postmaster death
List pgsql-hackers
On Thu, Oct 29, 2020 at 5:36 PM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> 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.

Interesting idea. One related case is where everything is fine on the
server side but the client has disconnected and we don't notice that
the socket has changed state until something makes us try to send a
message to the client, which might be a really long time if the
server's doing like a lengthy computation before generating any rows.
It would be really nice if we could find a cheap way to check for both
postmaster death and client disconnect every now and then, like if a
single system call could somehow answer both questions.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: John Naylor
Date:
Subject: Re: cutting down the TODO list thread
Next
From: Tomas Vondra
Date:
Subject: extended statistics - functional dependencies vs. MCV lists