Tom, thanks for the explanation!
My perspective as a libpq user is that multi-statement PQexec() should have the same effects as multiple PQexec() calls other than for the former dropping the results of all but the most recent statement. Rule (a) appears to break this assumption, and at minimum this difference should be documented?
As a practical matter, what I was trying to do is signal a test case that Postgres is in the middle of processing a transaction string. Rule (a) seems to mean that NOTIFY cannot be used for this. Is there some other mechanism? I don't want to depend on fragile timer-based logic such as "I've waited long enough so surely it is blocked in PQexec()"... that kind of thing always gets my test cases into trouble. This particular test case disrupts TCP during this state to ensure that reset logic works from this state.
Why do you think that it would break more clients than it fixes? Surely it is rare to end an explicit transaction containing a notify in a multi-statement command? For all other cases the behavior would be unchanged.
Thanks again,
John
John Muehlhausen <jgm@jgm.org> writes:
> Wrapping the notify in a transaction does not fix it. Shouldn't the notify
> be available as soon as the containing transaction is committed?
A notify message will be sent to the client when the backend is
(a) idle (*not* in the middle of processing a transaction string) and
(b) not in an open transaction.
You appear to be unhappy with point (a), but I think changing that
would break more clients than it fixes. It's intentional that
we don't send notifies mid-command, and this sure looks like a
variant of mid-command from here.
regards, tom lane