Andres Freund <> 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;
+               if (!pg_set_noblock(MyProcPort->sock))
+                       ereport(COMMERROR,
+                                       (errmsg("could not set socket to 
nonblocking mode: %m")));
+       }

> 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



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

Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to