Re: Escaping from blocked send() reprised.

On 2015-01-11 19:37:53 -0500, Noah Misch wrote:
> I recommend either (a) taking no action or (b) adding a regression test
> verifying WaitLatchOrSocket() conformance in this scenario.

Do you have a good idea how to test b) save a C function in regress.c
that does what your test does using latches?

> Then we cane decide what more to do if failure evidence emerges.

Seems fine to me.

> > Hm. I can think of two stopgap measures we could add:
> >
> > 1) If we're using select() and WL_SOCKET_WRITEABLE is set without
> > _READABLE, add a timeout of Min(1s, Max(passed_timeout, 1s)). As the
> > time spent waiting only for writable normally shouldn't be very long,
> > that shouldn't be noticeably bad for power usage.
> > 2) Add a SIGPIPE handler that just does a SetLatch(MyLach).
>
> I'm having trouble visualizing those proposed measures in detail, but I trust
> that a decent workaround would emerge.

For 1) I'm thinking of just regularly causing a spurious
WL_SOCKET_WRITEABLE event via timeouts if it's the only parameter. Latch
users have to deal with spurious wakeups anyway, so that should be
mostly unproblematic.

For 2) I was thinking that for now the problem only arises for the main
FE/BE socket. So we can install a sigpipe handler that does a SetLatch()
- that will trigger WaitLatch() to return and, after checking for
interrupts, retry the actual send() - which then'd return ECONNRESET.

> > What happens if you write/send() in
> > that state, btw?
>
> write() reports EAGAIN.

Grand.

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services