Re: Is PQreset() proper ? - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: Is PQreset() proper ?
Date
Msg-id 3A417C2B.D54C93EC@tpf.co.jp
Whole thread Raw
In response to Is PQreset() proper ?  ("Hiroshi Inoue" <Inoue@tpf.co.jp>)
Responses Re: Is PQreset() proper ?  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> 
> "Hiroshi Inoue" <Inoue@tpf.co.jp> 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


pgsql-hackers by date:

Previous
From: Hiroshi Inoue
Date:
Subject: Re: Isn't init_irels() dangerous ?
Next
From: Chris Ian Capon Fiel
Date:
Subject: Re: [GENERAL] Compiling on Win32