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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers