From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Qingqing Zhou <zhouqq(dot)postgres(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: rare avl shutdown slowness (related to signal handling) |
Date: | 2015-04-07 21:56:29 |
Message-ID: | 20150407215629.GO4369@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> That seems like (a) a hack, and (b) not likely to solve the problem
> completely, unless you leave interrupts held throughout proc_exit(),
> which would create all sorts of opportunities for corner case bugs
> during on_proc_exit hooks.
>
> I think changing the outer "for(;;)" to "while (!got_SIGTERM)" would
> be a much safer fix.
Ah, yeah. I was thinking in changing PG_exception_stack once shutdown
was requested, but this is much simpler.
> It looks like there's a related risk associated with this bit:
>
> /* in emergency mode, just start a worker and go away */
> if (!AutoVacuumingActive())
> {
> do_start_worker();
> proc_exit(0); /* done */
> }
>
> If we get SIGHUP and see that autovacuum has been turned off,
> we exit the main loop, but we don't set got_SIGTERM. So if we
> then get a similar error at the shutdown report, we'd not merely
> waste some time, but actually incorrectly launch a child.
Well, what it does is request a new child from postmaster, which
presumably wouldn't be listening; but yeah there's a lot of other work
done here also.
How about the attached?
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
autovac-shutdown.patch | text/x-diff | 1.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-04-07 22:13:13 | Re: rare avl shutdown slowness (related to signal handling) |
Previous Message | Tom Lane | 2015-04-07 21:32:37 | Re: rare avl shutdown slowness (related to signal handling) |