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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers