Tatsuo Ishii <is...@postgresql.org> writes:
>> The argument here could be do we really need a new state for such a short
>> window between completion of 'E' message and processing of 'S' sync
>> message considering updation of state is not a very light call which can
>> be called between processing of 2 messages. It might make sense for cases
>> where sync message processing can take longer time.
I concur with this objection --- we are not going to add reasons for
extended query mode to be slower than plain mode, especially not reasons
that are totally useless in normal usage.
> The query is piggy backed on the same connection to PostgreSQL opend
> by user (pgpool-II cannot issue "sync" because it closes the
> transaction, which in turn closes user's unnamed portal).
This argument (and usage) seems pretty broken. If you don't issue
sync then how do you know you've gotten all of the command's output?
If you're issuing a flush instead, maybe we could consider whether it's
reasonable to do an extra pgstat_report_activity() upon receipt of a
flush message. But -1 for putting it into the normal control flow.
I'd also vote against inventing a new pgstat state code for this.
Most people will never see it, which would prompt questions in itself.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
