Re: Re: SIGTERM does not stop backend postgres processes immediately

Hiroshi Inoue wrote:
>
> Christopher Faylor wrote:
> >
> > On Wed, May 09, 2001 at 02:26:29PM -0400, Jason Tishler wrote:
> > >> I know from inserting printfs into the backend code that the SIGTERM
> > >> signal handler function is not being called right after the stop
> > >> request. Rather, it is called only after the backend gets some data
> > >> over its input socket connection, from that "\d" in did in pg_ctl in
> > >> this case. It seems that the recv() call deep in the backend code
> > >> does not get interrupted by the SIGTERM.
> > >
>
> How about inserting a select() call before the recv() ?
> Cygwin's select() is interruptible AFAIK.
>

I see the following reply from Chris in cygwin's archive(I'm not
the member).

That would be the "workaround" that I kept mentioning previously.
It relies on polling and that is a something I'd rather avoid, if
possible.

My proposal is to pgsql-cygwin not to cygwin from the first.
The following is an example.

Comments ?

regards,
Hiroshi Inoue

{
#ifdef __CYGWIN__
fd_set rmask;
int nsocks;

FD_ZERO(&rmask);
FD_SET(MyProcPort->sock, &rmask);
nsocks = MyProcPort->sock + 1;
if (select(nsocks, &rmask, (fd_set *) NULL,
(fd_set *) NULL, (struct timeval *) NULL) < 0)
{
if (errno == EINTR)
continue;
fprintf(stderr, "pq_recvbuf: select()
failed: %s\n",
strerror(errno));
return EOF;
}
#endif /* __CYGWIN__ */
r = recv(MyProcPort->sock, PqRecvBuffer +
PqRecvLength,
PQ_BUFFER_SIZE - PqRecvLength,
0);

}