Tom Lane wrote:
>
> "Hiroshi Inoue" <[EMAIL PROTECTED]> writes:
> > postmaster: BackendStartup: pid 395 user reindex db reindex socket 5
> > DEBUG: exit(2)
> > postmaster: reaping dead processes...
> > postmaster: CleanupProc: pid 394 exited with status 512
> > Server process (pid 394) exited with status 512 at Tue Dec 19 20:12:41 2000
> > Terminating any active server processes...
> > postmaster: CleanupProc: sending SIGUSR1 to process 395
> > postmaster child[395]: starting with (postgres -d2 -v131072 -p reindex )
>
> 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.
>
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.
Regards.
Hiroshi Inoue
- [HACKERS] Is PQreset() proper ? Hiroshi Inoue
- Re: [HACKERS] Is PQreset() proper ? Tom Lane
- Re: [HACKERS] Is PQreset() proper ? Hiroshi Inoue
- Re: [HACKERS] Is PQreset() proper ? Tom Lane