Re: NOTIFY in multi-statement PQexec() not sent outside of transaction

>
>
>
> > 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.
>
> Well, that's not even close to true, because of the rules about statements
> within a multi-statement string getting merged into single transactions.
>

My meaning was that with appropriate begin/commit augmentation, the user
should be able to achieve the same effects with multi-statement, and that
Rule (a) makes this unachievable, at least in the case of NOTIFY.

My goal is to write a test case where the service being tested (which is a
child process of the testing process) is known to be blocking in a PQexec
call, and during this exact state the testing process disrupts the TCP
connection between the service and postgres in various ways, to be sure
that the service recovers.

I'm not sure how to know that PQexec() has entered and not yet returned in
my service process other than to examine the effects of a partially
complete PQexec() itself. If I can't use NOTIFY then perhaps I can sniff
for the network traffic sent at the beginning of PQexec(), or perhaps there
is some extra libpq logging I could enable to know that PQexec() is in
process?

Still, even without considering my usage, I find it odd that this would not
be considered a bug, for the reason in my first sentence above. The
current behavior means that the user has to think about transactions "and
something else" when reasoning about the effects of statements. I would
vote to remove the "and something else" which would then remove the need to
augment the current documentation. As it stands, at minimum, the
documentation needs to warn the user that similar notify effects are
unachievable in the multi-statement realm?

-John