Skip site navigation (1) Skip section navigation (2)

Fix issuing of multiple command completions per command

From: Fernando Nasser <fnasser(at)redhat(dot)com>
To: pgsql-patches(at)postgresql(dot)org
Subject: Fix issuing of multiple command completions per command
Date: 2002-02-22 14:39:13
Message-ID: 3C765811.71C714C8@redhat.com (view raw or flat)
Thread:
Lists: pgsql-patches
(Please note that "[PATCHES] Allow arbitrary levels of
analyze/rewriting"
must be applied before this patch)

This patch prevents the issue of multiple command completions
when queries are rewritten into a sequence queries by analyze/rewrite.
Currently the front ends are receiving many;  libpq just uses the last
one received so that is why we see only one response in psql, for 
instance.

It fixes a bug where the user receives a bogus completion message 
for queries that have been turned into a sequence of queries where
the last one has a different completion tag.

It also prevents command-completions to be generated by utility commands
that are inside SQL-functions.

It also fixes some misplaced calls to set ps_status.

Furthermore, these changes made possible to reduce the number of
times ps_status is set (a request from Tom Lane). This is done by
default but it is still possible to set a compiler flag and have
it generate more calls as it does today (one for each query produced
by the rewriting of the original query).


Here is basically what is done:

The completion is sent by EndCommand().  This call is used OK by
plannable queries and is necessary there for telling that the data
sent to a backend has come to an end.  Utilities, however, don't
send any data (except FETCH) and may be rewritten into a series of
other utility queries.  The changes consolidate the calls to
EndCommand() for utility queries and let the plannable ones 
handle it pairwise with BeginCommand() (which is not used by
utility queries).


ChangeLog:

        * src/backend/commands/command.c (PerformPortalFetch): Send
        command completion so that fe knows we are done with sending
data.
        * src/backend/commands/explain.c (ExplainOneQuery): Set
ps_status
        to EXPLAIN or SELECT (for the EXPLAIN ANALYZE case).  
        * src/backend/executor/functions.c (postquel_getnext): Do not
send
        command completion messages for utilities inside SQL-functions
        (one will be sent for the command that invoked the function).  
        * src/backend/executor/spi.c (_SPI_execute, _SPI_execute_plan):
Add
        comments.  
        * src/backend/tcop/postgres.c (pg_exec_query_string):
        Do not send a command completion message or set the ps_status
for
        each utility query that results for the rewriting of a command;
        just send one for the original command.  Let plannable queries
take
        care of their own completion.
        (CreateCommandTag): New function.  Create a command completion
tag
        based on the parse tree node (rather than on an already/analyzed
        query node).  
        * src/backend/tcop/utility.c (ProcessUtility): Do
        not meddle with ps_status or command completion in this
function.
        * src/backend/tcop/pquery.c (ProcessQuery): Let the caller set
        ps_status.





-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser(at)redhat(dot)com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Attachment: COMPLETE.PATCH
Description: text/plain (38.8 KB)

Responses

pgsql-patches by date

Next:From: Fernando NasserDate: 2002-02-22 14:44:13
Subject: Fix command completion for CREATE TABEL ... AS
Previous:From: Bruce MomjianDate: 2002-02-22 13:08:11
Subject: Re: [PATCHES] Re: nocreatetable for 7.1.2 [patch]

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group