Re: SIGUSR1 pingpong between master na autovacum launcher causes crash

Zdenek Kotala wrote:

> The problem what I see here is that StartAutovacuumWorker() fails and
> send SIGUSR1 to the postmaster, but it send it too quickly and signal
> handler is still active. When signal mask is unblocked in
> sigusr1_handler() than signal handler is run again...
>
> The reason why StartAutovacuumWorker() is interesting. Log says:
>
> LOG: could not fork autovacuum worker process: Not enough space

Does this mean that the machine is out of swap space?

> It is strange and I don't understand it. May be too many nested signal
> handlers call could cause it.
>
> Strange also is that 100ms is not enough to protect this situation, but
> I think that sleep could interrupted by signal.
>
> My suggestion is to set for example gotUSR1=true in sigusr1_handler()
> and in the server loop check if we got a USR1 signal. It avoids any
> problems with signal handler which is not currently POSIX compliant
> anyway.

What 100ms? The pg_usleep call you see in ServerLoop is only there
during shutdown; normally it would be the select() call that would be
blocking the process.

If sigusr1_handler needs rewriting, don't all the other sighandler as
well? Note that the process is supposed to be running with signals
blocked all the time except during those sleep/select calls, which is
what (according to comments) let the sighandlers do nontrivial tasks.

--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.