Re: Is PQreset() proper ?

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Is PQreset() proper ?
Date: 2000-12-21 03:42:35
Message-ID: 3A417C2B.D54C93EC@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
>
> "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Ian Capon Fiel 2000-12-21 03:55:44 Re: Compiling on Win32
Previous Message Hiroshi Inoue 2000-12-21 00:26:58 Re: Isn't init_irels() dangerous ?