Re: Escaping from blocked send() reprised.
Andres Freund <andres@2ndquadrant.com>
From: Andres Freund <andres@2ndquadrant.com>
To: Alex Shulgin <ash@commandprompt.com>
Cc: Heikki Linnakangas <hlinnakangas@vmware.com>,
Tom Lane <tgl@sss.pgh.pa.us>,
Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
robertmhaas@gmail.com, pgsql-hackers@postgresql.org
Date: 2015-01-10T01:59:07Z
Lists: pgsql-hackers
On 2014-11-17 18:22:54 +0300, Alex Shulgin wrote:
>
> Andres Freund <andres@2ndquadrant.com> writes:
> >
> > I've invested some more time in this:
> > 0002 now makes sense on its own and doesn't change anything around the
> > interrupt handling. Oh, and it compiles without 0003.
>
> In this patch, the endif appears to be misplaced in PostgresMain:
>
> + if (MyProcPort != NULL)
> + {
> +#ifdef WIN32
> + pgwin32_noblock = true;
> +#else
> + if (!pg_set_noblock(MyProcPort->sock))
> + ereport(COMMERROR,
> + (errmsg("could not set socket to nonblocking mode: %m")));
> + }
> +#endif
> +
Uh. Odd. Anyway, that bit of code is now somewhere else anyway...
> One thing I did try is sending a NOTICE to the client when in
> ProcessInterrupts() and DoingCommandRead is true. I think[1] it was
> expected to be delivered instantly, but actually the client (psql) only
> displays it after sending the next statement.
Yea, that should be psql specific though. I hope ;)
> While I'm reading on FE/BE protocol someone might want to share his
> wisdom on this subject. My guess: psql blocks on readline/libedit call
> and can't effectively poll the server socket before complete input from
> user.
I'm not sure if it's actually a "can't". It doesn't at least ;)
Greetings,
Andres Freund
Commits
-
Assert that WaitLatchOrSocket callers cannot wait only for writability.
- e42a21b9e6c9 9.2.0 cited