Re: Escaping from blocked send() reprised. - Mailing list pgsql-hackers

From Alex Shulgin
Subject Re: Escaping from blocked send() reprised.
Date
Msg-id 87y4r9n969.fsf@commandprompt.com
Whole thread Raw
In response to Re: Escaping from blocked send() reprised.  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: Escaping from blocked send() reprised.  (Andres Freund <andres@2ndquadrant.com>)
List pgsql-hackers
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.''



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Wait free LW_SHARED acquisition - v0.2
Next
From: Andres Freund
Date:
Subject: Re: Wait free LW_SHARED acquisition - v0.2