Alvaro Herrera <alvhe...@commandprompt.com> writes:
> Tom Lane wrote:
>> It does seem that we ought to change things so that there's a bit more
>> delay before trying to re-launch a failed autovac worker, though.
>> Whatever caused this was effectively turning the autovac logic into
>> a fork-bomb engine. I'm not thinking of just postponing the relaunch
>> into the main loop, but ensuring at least a few hundred msec delay before
>> we try again.
> Would it be enough to move the kill() syscall into ServerLoop in
> postmaster.c instead of letting it be called in the signal handler, per
> the attached patch? This way the signal is not delayed, but we exit the
> signal handler before doing it.
I'd still like to have some fork-rate-limiting behavior in there
somewhere. However, it might make sense for the avlauncher to do that
rather than the postmaster. Does that idea seem more implementable?
(If the launcher implements a minimum delay between requests then it
really doesn't matter whether we apply this patch or not, and I'd be
inclined to leave the postmaster alone rather than add yet more state.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
