Fernando Nasser wrote:
>
> Tom Lane wrote:
> >
> > 2. EndCommand should *not* be issued until we have completed all the
> > actions of the (rewritten) query. Moving EndCommand into
> > PerformPortalFetch, as you did here, is exactly the wrong direction.
> > What we need is for EndCommand to be executed from pg_exec_query_string.
> > That means that the tag auxiliary info (currently set up by
> > UpdateCommandInfo) has to be passed out from ProcessQuery to
> > pg_exec_query_string, which is the only place that can know when to send
> > the command completion notice back to the client.
> >
>
> That was my first impression, but after I looked more deeply into it
> I figured that this is the right thing to do (I explain it below).
>
> And remember that there is still the 'Z'. This completion will close
> the
> flow of data packets that may have been sent. It is good for the
> async processing as well as the application may process the data
> while waiting for the 'Z' (otherwise it will not know that all the
> data has arrived).
>
OK, I take this back. I see your point now. We don't want async
processing to resume before all the extras_after are processed
because we want all these side effects to be perceived by whoever
is doing the processing. So it doesn't matter that the data has
already arrived or not -- one has to wait.
It seems a small change though. I believe I can safely let
pg_exec_query_string do all the EndCommand() calls. I would just
have to add your suggested change to get the CommandInfo as well.
Let me know if you want me to try that.
--
Fernando Nasser
Red Hat Canada Ltd. E-Mail: fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario M4P 2C9