On Fri, 5 Jan 2001 14:13:11 -0500
Jason Tishler <Jason.Tishler@dothill.com> wrote:
> I am observing the following postmaster shutdown problem with 7.0.3 and
> the 12/29/2000 snapshot on Cygwin 1.1.7:
>
> After postmaster has been driven by multiple simultaneous (JDBC)
> connections, postmaster usually requires to receive more the one
> SIGTERM signal before it will perform a Smart Shutdown.
>
> When I run the 7.0.3 postmaster with the "-d 1" option, I get the
> following pruned and annotated (indicated by the ### prefix) output for
> two simultaneous connections:
>
> ...
> ### last JDBC connection is dropped by client
> pq_recvbuf: recv() failed: Connection reset by peer
> proc_exit(0)
> shmem_exit(0)
> exit(0)
> /usr/local/pgsql/bin/postmaster: reaping dead processes...
> /usr/local/pgsql/bin/postmaster: CleanupProc: pid 461 exited with status 0
> /usr/local/pgsql/bin/postmaster: CleanupProc: pid 406 exited with status 0
> /usr/local/pgsql/bin/postmaster: CleanupProc: pid 358 exited with status 0
> /usr/local/pgsql/bin/postmaster: reaping dead processes...
> ### first SIGTERM signal received
> /usr/local/pgsql/bin/postmaster: reaping dead processes...
> /usr/local/pgsql/bin/postmaster: reaping dead processes...
> ### second SIGTERM signal received
> pmdie 15
> Smart Shutdown request at Fri Jan 5 13:47:13 2001
> ...
>
> The above output seems to indicate that reaper() is firing instead of
> pmdie() when the first SIGTERM is signal received. Hmm...
>
> If postmaster is driven by only one connection, then it always shutdowns
> on the first SIGTERM signal. If postmaster is driven by more than two
> connections, then it can require three or more SIGTERM signals.
>
> I have *not* been able to reproduce this problem with 7.0.3 on Red Hat
> 6.2 Linux.
>
> Is this a known problem? Has anyone else observed this problem on a
> platform other than Cygwin? This information would be helpful before I
> start trudging through the Cygwin DLL...
It's a bug of cygipc.
Cygipc can't catch signals when waiting with semget().I'm trying to fix
this.
--
Yutaka tanida<yutaka@hi-net.zaq.ne.jp>