Re: Is PQreset() proper ?

> Tom Lane wrote:
>> This isn't PQreset()'s fault that I can see. This is a race condition
>> caused by bogosity in PostgresMain --- it enables SIGUSR1 before it's
>> set up the correct signal handler for same. The postmaster should have
>> started the child process with all signals blocked, so SIGUSR1 will be
>> held off until the child explicitly enables it; but it does so a few
>> lines too soon. Will fix.

Actually, it turns out the real problem is that backends were inheriting
a SIG_IGN setting for SIGUSR1 from the postmaster. So a SIGUSR1
delivered before they got as far as setting up their own signal handling
would get lost. Fixed now.

Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> I once observed another case,the hang of CheckPoint process
> while postmaster was in a backend crash recovery. I changed
> postmaster.c to not invoke CheckPoint process while postmaster
> is in a backend crash recovery but it doesn't seem sufficient.
> SIGUSR1 signal seems to be blocked all the way in CheckPoint
> process.

Hm. Vadim, do you think it's safe to let CheckPoint be killed by
SIGUSR1? If not, what will we do about this?

regards, tom lane