From: | Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> |
---|---|
To: | pgsql-cygwin(at)postgresql(dot)org |
Subject: | Re: Re: SIGTERM does not stop backend postgres processes immediately |
Date: | 2001-05-15 01:30:39 |
Message-ID: | 3B0086BF.C0CEC6EA@tpf.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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);
}
From | Date | Subject | |
---|---|---|---|
Next Message | Henshall, Stuart - WCP | 2001-05-15 08:58:09 | RE: Postgres server on Windows 98 |
Previous Message | Ray Golish | 2001-05-14 19:38:39 | postgresql client under win 2k |