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@tpf.co.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