Re: Re: SIGTERM does not stop backend postgres processes immediately - Mailing list pgsql-cygwin

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);

                }