Re: Escaping from blocked send() reprised.

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
+
 	pqinitmask();

> 0003 Sinval/notify processing got simplified further. There really isn't
>      any need for DisableNotifyInterrupt/DisableCatchupInterrupt
>      anymore. Also begin_client_read/client_read_ended don't make much
>      sense anymore. Instead introduce ProcessClientReadInterrupt (which
>      wants a better name).
> There's also a very WIP
> 0004 Allows secure_read/write be interrupted when ProcDiePending is
>      set. All of that happens via the latch mechanism, nothing happens
>      inside signal handlers. So I do think it's quite an improvement
>      over what's been discussed in this thread.
>      But it (and the other approaches) do noticeably increase the
>      likelihood of clients not getting the error message if the client
>      isn't actually dead. The likelihood of write() being blocked
>      *temporarily* due to normal bandwidth constraints is quite high
>      when you consider COPY FROM and similar. Right now we'll wait till
>      we can put the error message into the socket afaics.
>
> 1-3 need some serious comment work, but I think the approach is
> basically sound. I'm much, much less sure about allowing send() to be
> interrupted.

After re-reading these I don't see the rest of items I wanted to inqury
about anymore, so it just makes more sense now.

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.

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.

--
Alex

[1] http://www.postgresql.org/message-id/1262173040.19367.5015.camel@ebony

  ``AFAIK, NOTICE was suggested because it can be sent at any time,
    whereas ERRORs are only associated with statements.''