1996-07-09 08:22:35 +02:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
*
|
1999-02-14 00:22:53 +01:00
|
|
|
* dest.c
|
2002-02-27 20:36:13 +01:00
|
|
|
* support for communication destinations
|
|
|
|
*
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
2016-01-02 19:33:40 +01:00
|
|
|
* Portions Copyright (c) 1996-2016, PostgreSQL Global Development Group
|
2000-01-26 06:58:53 +01:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
* IDENTIFICATION
|
2010-09-20 22:08:53 +02:00
|
|
|
* src/backend/tcop/dest.c
|
1996-07-09 08:22:35 +02:00
|
|
|
*
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
*/
|
|
|
|
/*
|
1997-09-07 07:04:48 +02:00
|
|
|
* INTERFACE ROUTINES
|
2002-02-27 20:36:13 +01:00
|
|
|
* BeginCommand - initialize the destination at start of command
|
2003-05-06 22:26:28 +02:00
|
|
|
* CreateDestReceiver - create tuple receiver object for destination
|
2002-02-27 20:36:13 +01:00
|
|
|
* EndCommand - clean up the destination at end of command
|
1998-05-07 01:51:16 +02:00
|
|
|
* NullCommand - tell dest that an empty query string was recognized
|
|
|
|
* ReadyForQuery - tell dest that we are ready for a new query
|
1997-09-07 07:04:48 +02:00
|
|
|
*
|
|
|
|
* NOTES
|
|
|
|
* These routines do the appropriate work before and after
|
|
|
|
* tuples are returned by a query to keep the backend and the
|
|
|
|
* "destination" portals synchronized.
|
1996-07-09 08:22:35 +02:00
|
|
|
*/
|
1997-01-10 21:19:49 +01:00
|
|
|
|
1996-07-09 08:22:35 +02:00
|
|
|
#include "postgres.h"
|
|
|
|
|
1999-07-16 07:00:38 +02:00
|
|
|
#include "access/printtup.h"
|
2003-04-26 22:23:00 +02:00
|
|
|
#include "access/xact.h"
|
2006-08-31 01:34:22 +02:00
|
|
|
#include "commands/copy.h"
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
#include "commands/createas.h"
|
2013-03-04 01:23:31 +01:00
|
|
|
#include "commands/matview.h"
|
2008-10-31 20:37:56 +01:00
|
|
|
#include "executor/functions.h"
|
Glue layer to connect the executor to the shm_mq mechanism.
The shm_mq mechanism was built to send error (and notice) messages and
tuples between backends. However, shm_mq itself only deals in raw
bytes. Since commit 2bd9e412f92bc6a68f3e8bcb18e04955cc35001d, we have
had infrastructure for one message to redirect protocol messages to a
queue and for another backend to parse them and do useful things with
them. This commit introduces a somewhat analogous facility for tuples
by adding a new type of DestReceiver, DestTupleQueue, which writes
each tuple generated by a query into a shm_mq, and a new
TupleQueueFunnel facility which reads raw tuples out of the queue and
reconstructs the HeapTuple format expected by the executor.
The TupleQueueFunnel abstraction supports reading from multiple tuple
streams at the same time, but only in round-robin fashion. Someone
could imaginably want other policies, but this should be good enough
to meet our short-term needs related to parallel query, and we can
always extend it later.
This also makes one minor addition to the shm_mq API that didn'
seem worth breaking out as a separate patch.
Extracted from Amit Kapila's parallel sequential scan patch. This
code was originally written by me, and then it was revised by Amit,
and then it was revised some more by me.
2015-09-19 03:10:08 +02:00
|
|
|
#include "executor/tqueue.h"
|
2003-05-08 20:16:37 +02:00
|
|
|
#include "executor/tstoreReceiver.h"
|
1998-01-26 02:42:53 +01:00
|
|
|
#include "libpq/libpq.h"
|
1999-04-25 05:19:27 +02:00
|
|
|
#include "libpq/pqformat.h"
|
2003-05-08 20:16:37 +02:00
|
|
|
#include "utils/portal.h"
|
1996-07-09 08:22:35 +02:00
|
|
|
|
|
|
|
|
|
|
|
/* ----------------
|
1999-01-27 01:36:28 +01:00
|
|
|
* dummy DestReceiver functions
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
2016-06-06 20:52:58 +02:00
|
|
|
static bool
|
2005-03-16 22:38:10 +01:00
|
|
|
donothingReceive(TupleTableSlot *slot, DestReceiver *self)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2016-06-06 20:52:58 +02:00
|
|
|
return true;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
1999-01-27 01:36:28 +01:00
|
|
|
static void
|
2003-05-08 20:16:37 +02:00
|
|
|
donothingStartup(DestReceiver *self, int operation, TupleDesc typeinfo)
|
1999-01-27 01:36:28 +01:00
|
|
|
{
|
|
|
|
}
|
1997-08-29 11:06:27 +02:00
|
|
|
|
1999-01-27 01:36:28 +01:00
|
|
|
static void
|
1999-05-26 00:43:53 +02:00
|
|
|
donothingCleanup(DestReceiver *self)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
2003-05-06 22:26:28 +02:00
|
|
|
/* this is used for both shutdown and destroy methods */
|
1999-01-27 01:36:28 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------
|
|
|
|
* static DestReceiver structs for dest types needing no local state
|
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
static DestReceiver donothingDR = {
|
2003-05-06 22:26:28 +02:00
|
|
|
donothingReceive, donothingStartup, donothingCleanup, donothingCleanup,
|
2005-11-03 18:11:40 +01:00
|
|
|
DestNone
|
1999-01-27 01:36:28 +01:00
|
|
|
};
|
This patch implements holdable cursors, following the proposal
(materialization into a tuple store) discussed on pgsql-hackers earlier.
I've updated the documentation and the regression tests.
Notes on the implementation:
- I needed to change the tuple store API slightly -- it assumes that it
won't be used to hold data across transaction boundaries, so the temp
files that it uses for on-disk storage are automatically reclaimed at
end-of-transaction. I added a flag to tuplestore_begin_heap() to control
this behavior. Is changing the tuple store API in this fashion OK?
- in order to store executor results in a tuple store, I added a new
CommandDest. This works well for the most part, with one exception: the
current DestFunction API doesn't provide enough information to allow the
Executor to store results into an arbitrary tuple store (where the
particular tuple store to use is chosen by the call site of
ExecutorRun). To workaround this, I've temporarily hacked up a solution
that works, but is not ideal: since the receiveTuple DestFunction is
passed the portal name, we can use that to lookup the Portal data
structure for the cursor and then use that to get at the tuple store the
Portal is using. This unnecessarily ties the Portal code with the
tupleReceiver code, but it works...
The proper fix for this is probably to change the DestFunction API --
Tom suggested passing the full QueryDesc to the receiveTuple function.
In that case, callers of ExecutorRun could "subclass" QueryDesc to add
any additional fields that their particular CommandDest needed to get
access to. This approach would work, but I'd like to think about it for
a little bit longer before deciding which route to go. In the mean time,
the code works fine, so I don't think a fix is urgent.
- (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and
adjusted the behavior of SCROLL in accordance with the discussion on
-hackers.
- (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml
Neil Conway
2003-03-27 17:51:29 +01:00
|
|
|
|
1999-01-27 01:36:28 +01:00
|
|
|
static DestReceiver debugtupDR = {
|
2003-05-06 22:26:28 +02:00
|
|
|
debugtup, debugStartup, donothingCleanup, donothingCleanup,
|
2005-11-03 18:11:40 +01:00
|
|
|
DestDebug
|
1999-01-27 01:36:28 +01:00
|
|
|
};
|
This patch implements holdable cursors, following the proposal
(materialization into a tuple store) discussed on pgsql-hackers earlier.
I've updated the documentation and the regression tests.
Notes on the implementation:
- I needed to change the tuple store API slightly -- it assumes that it
won't be used to hold data across transaction boundaries, so the temp
files that it uses for on-disk storage are automatically reclaimed at
end-of-transaction. I added a flag to tuplestore_begin_heap() to control
this behavior. Is changing the tuple store API in this fashion OK?
- in order to store executor results in a tuple store, I added a new
CommandDest. This works well for the most part, with one exception: the
current DestFunction API doesn't provide enough information to allow the
Executor to store results into an arbitrary tuple store (where the
particular tuple store to use is chosen by the call site of
ExecutorRun). To workaround this, I've temporarily hacked up a solution
that works, but is not ideal: since the receiveTuple DestFunction is
passed the portal name, we can use that to lookup the Portal data
structure for the cursor and then use that to get at the tuple store the
Portal is using. This unnecessarily ties the Portal code with the
tupleReceiver code, but it works...
The proper fix for this is probably to change the DestFunction API --
Tom suggested passing the full QueryDesc to the receiveTuple function.
In that case, callers of ExecutorRun could "subclass" QueryDesc to add
any additional fields that their particular CommandDest needed to get
access to. This approach would work, but I'd like to think about it for
a little bit longer before deciding which route to go. In the mean time,
the code works fine, so I don't think a fix is urgent.
- (semi-related) I added a NO SCROLL keyword to DECLARE CURSOR, and
adjusted the behavior of SCROLL in accordance with the discussion on
-hackers.
- (unrelated) Cleaned up some SGML markup in sql.sgml, copy.sgml
Neil Conway
2003-03-27 17:51:29 +01:00
|
|
|
|
1999-01-27 01:36:28 +01:00
|
|
|
static DestReceiver spi_printtupDR = {
|
2003-05-06 22:26:28 +02:00
|
|
|
spi_printtup, spi_dest_startup, donothingCleanup, donothingCleanup,
|
2005-11-03 18:11:40 +01:00
|
|
|
DestSPI
|
1999-01-27 01:36:28 +01:00
|
|
|
};
|
|
|
|
|
2005-11-03 18:11:40 +01:00
|
|
|
/* Globally available receiver for DestNone */
|
2003-05-06 22:26:28 +02:00
|
|
|
DestReceiver *None_Receiver = &donothingDR;
|
|
|
|
|
|
|
|
|
1999-01-27 01:36:28 +01:00
|
|
|
/* ----------------
|
2002-02-27 20:36:13 +01:00
|
|
|
* BeginCommand - initialize the destination at start of command
|
1999-01-27 01:36:28 +01:00
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
2002-02-27 20:36:13 +01:00
|
|
|
BeginCommand(const char *commandTag, CommandDest dest)
|
1999-01-27 01:36:28 +01:00
|
|
|
{
|
2002-02-27 20:36:13 +01:00
|
|
|
/* Nothing to do at present */
|
1999-01-27 01:36:28 +01:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------
|
2003-05-06 22:26:28 +02:00
|
|
|
* CreateDestReceiver - return appropriate receiver function set for dest
|
1999-01-27 01:36:28 +01:00
|
|
|
* ----------------
|
|
|
|
*/
|
1999-05-25 18:15:34 +02:00
|
|
|
DestReceiver *
|
2008-11-30 21:51:25 +01:00
|
|
|
CreateDestReceiver(CommandDest dest)
|
1999-01-27 01:36:28 +01:00
|
|
|
{
|
|
|
|
switch (dest)
|
|
|
|
{
|
2005-11-03 18:11:40 +01:00
|
|
|
case DestRemote:
|
|
|
|
case DestRemoteExecute:
|
2008-11-30 21:51:25 +01:00
|
|
|
return printtup_create_DR(dest);
|
2003-05-05 02:44:56 +02:00
|
|
|
|
2005-11-03 18:11:40 +01:00
|
|
|
case DestNone:
|
2003-05-05 02:44:56 +02:00
|
|
|
return &donothingDR;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2005-11-03 18:11:40 +01:00
|
|
|
case DestDebug:
|
1999-05-25 18:15:34 +02:00
|
|
|
return &debugtupDR;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2005-11-03 18:11:40 +01:00
|
|
|
case DestSPI:
|
1999-05-25 18:15:34 +02:00
|
|
|
return &spi_printtupDR;
|
1997-09-07 07:04:48 +02:00
|
|
|
|
2005-11-03 18:11:40 +01:00
|
|
|
case DestTuplestore:
|
2008-11-30 21:51:25 +01:00
|
|
|
return CreateTuplestoreDestReceiver();
|
2006-08-12 04:52:06 +02:00
|
|
|
|
|
|
|
case DestIntoRel:
|
Restructure SELECT INTO's parsetree representation into CreateTableAsStmt.
Making this operation look like a utility statement seems generally a good
idea, and particularly so in light of the desire to provide command
triggers for utility statements. The original choice of representing it as
SELECT with an IntoClause appendage had metastasized into rather a lot of
places, unfortunately, so that this patch is a great deal more complicated
than one might at first expect.
In particular, keeping EXPLAIN working for SELECT INTO and CREATE TABLE AS
subcommands required restructuring some EXPLAIN-related APIs. Add-on code
that calls ExplainOnePlan or ExplainOneUtility, or uses
ExplainOneQuery_hook, will need adjustment.
Also, the cases PREPARE ... SELECT INTO and CREATE RULE ... SELECT INTO,
which formerly were accepted though undocumented, are no longer accepted.
The PREPARE case can be replaced with use of CREATE TABLE AS EXECUTE.
The CREATE RULE case doesn't seem to have much real-world use (since the
rule would work only once before failing with "table already exists"),
so we'll not bother with that one.
Both SELECT INTO and CREATE TABLE AS still return a command tag of
"SELECT nnnn". There was some discussion of returning "CREATE TABLE nnnn",
but for the moment backwards compatibility wins the day.
Andres Freund and Tom Lane
2012-03-20 02:37:19 +01:00
|
|
|
return CreateIntoRelDestReceiver(NULL);
|
2006-08-31 01:34:22 +02:00
|
|
|
|
|
|
|
case DestCopyOut:
|
|
|
|
return CreateCopyDestReceiver();
|
2008-10-31 20:37:56 +01:00
|
|
|
|
|
|
|
case DestSQLFunction:
|
|
|
|
return CreateSQLFunctionDestReceiver();
|
2013-03-04 01:23:31 +01:00
|
|
|
|
|
|
|
case DestTransientRel:
|
|
|
|
return CreateTransientRelDestReceiver(InvalidOid);
|
Glue layer to connect the executor to the shm_mq mechanism.
The shm_mq mechanism was built to send error (and notice) messages and
tuples between backends. However, shm_mq itself only deals in raw
bytes. Since commit 2bd9e412f92bc6a68f3e8bcb18e04955cc35001d, we have
had infrastructure for one message to redirect protocol messages to a
queue and for another backend to parse them and do useful things with
them. This commit introduces a somewhat analogous facility for tuples
by adding a new type of DestReceiver, DestTupleQueue, which writes
each tuple generated by a query into a shm_mq, and a new
TupleQueueFunnel facility which reads raw tuples out of the queue and
reconstructs the HeapTuple format expected by the executor.
The TupleQueueFunnel abstraction supports reading from multiple tuple
streams at the same time, but only in round-robin fashion. Someone
could imaginably want other policies, but this should be good enough
to meet our short-term needs related to parallel query, and we can
always extend it later.
This also makes one minor addition to the shm_mq API that didn'
seem worth breaking out as a separate patch.
Extracted from Amit Kapila's parallel sequential scan patch. This
code was originally written by me, and then it was revised by Amit,
and then it was revised some more by me.
2015-09-19 03:10:08 +02:00
|
|
|
|
|
|
|
case DestTupleQueue:
|
|
|
|
return CreateTupleQueueDestReceiver(NULL);
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
|
|
|
|
2002-02-27 20:36:13 +01:00
|
|
|
/* should never get here */
|
1999-05-25 18:15:34 +02:00
|
|
|
return &donothingDR;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------
|
2002-02-27 20:36:13 +01:00
|
|
|
* EndCommand - clean up the destination at end of command
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
2002-02-26 23:47:12 +01:00
|
|
|
EndCommand(const char *commandTag, CommandDest dest)
|
1996-07-09 08:22:35 +02:00
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
switch (dest)
|
|
|
|
{
|
2005-11-03 18:11:40 +01:00
|
|
|
case DestRemote:
|
|
|
|
case DestRemoteExecute:
|
2010-02-26 03:01:40 +01:00
|
|
|
|
2010-01-30 21:09:53 +01:00
|
|
|
/*
|
2010-02-26 03:01:40 +01:00
|
|
|
* We assume the commandTag is plain ASCII and therefore requires
|
|
|
|
* no encoding conversion.
|
2010-01-30 21:09:53 +01:00
|
|
|
*/
|
|
|
|
pq_putmessage('C', commandTag, strlen(commandTag) + 1);
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
|
|
|
|
2005-11-03 18:11:40 +01:00
|
|
|
case DestNone:
|
|
|
|
case DestDebug:
|
|
|
|
case DestSPI:
|
|
|
|
case DestTuplestore:
|
2006-08-12 04:52:06 +02:00
|
|
|
case DestIntoRel:
|
2006-08-31 01:34:22 +02:00
|
|
|
case DestCopyOut:
|
2008-10-31 20:37:56 +01:00
|
|
|
case DestSQLFunction:
|
2013-03-04 01:23:31 +01:00
|
|
|
case DestTransientRel:
|
Glue layer to connect the executor to the shm_mq mechanism.
The shm_mq mechanism was built to send error (and notice) messages and
tuples between backends. However, shm_mq itself only deals in raw
bytes. Since commit 2bd9e412f92bc6a68f3e8bcb18e04955cc35001d, we have
had infrastructure for one message to redirect protocol messages to a
queue and for another backend to parse them and do useful things with
them. This commit introduces a somewhat analogous facility for tuples
by adding a new type of DestReceiver, DestTupleQueue, which writes
each tuple generated by a query into a shm_mq, and a new
TupleQueueFunnel facility which reads raw tuples out of the queue and
reconstructs the HeapTuple format expected by the executor.
The TupleQueueFunnel abstraction supports reading from multiple tuple
streams at the same time, but only in round-robin fashion. Someone
could imaginably want other policies, but this should be good enough
to meet our short-term needs related to parallel query, and we can
always extend it later.
This also makes one minor addition to the shm_mq API that didn'
seem worth breaking out as a separate patch.
Extracted from Amit Kapila's parallel sequential scan patch. This
code was originally written by me, and then it was revised by Amit,
and then it was revised some more by me.
2015-09-19 03:10:08 +02:00
|
|
|
case DestTupleQueue:
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
1997-09-07 07:04:48 +02:00
|
|
|
}
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------
|
1998-05-07 01:51:16 +02:00
|
|
|
* NullCommand - tell dest that an empty query string was recognized
|
1997-09-07 07:04:48 +02:00
|
|
|
*
|
1998-05-07 01:51:16 +02:00
|
|
|
* In FE/BE protocol version 1.0, this hack is necessary to support
|
|
|
|
* libpq's crufty way of determining whether a multiple-command
|
|
|
|
* query string is done. In protocol 2.0 it's probably not really
|
|
|
|
* necessary to distinguish empty queries anymore, but we still do it
|
2003-04-22 02:08:07 +02:00
|
|
|
* for backwards compatibility with 1.0. In protocol 3.0 it has some
|
|
|
|
* use again, since it ensures that there will be a recognizable end
|
|
|
|
* to the response to an Execute message.
|
1996-07-09 08:22:35 +02:00
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
NullCommand(CommandDest dest)
|
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
switch (dest)
|
|
|
|
{
|
2005-11-03 18:11:40 +01:00
|
|
|
case DestRemote:
|
|
|
|
case DestRemoteExecute:
|
2001-03-22 07:16:21 +01:00
|
|
|
|
|
|
|
/*
|
2005-10-15 04:49:52 +02:00
|
|
|
* tell the fe that we saw an empty query string. In protocols
|
|
|
|
* before 3.0 this has a useless empty-string message body.
|
1999-01-27 01:36:28 +01:00
|
|
|
*/
|
2003-04-22 02:08:07 +02:00
|
|
|
if (PG_PROTOCOL_MAJOR(FrontendProtocol) >= 3)
|
|
|
|
pq_putemptymessage('I');
|
|
|
|
else
|
2010-01-30 21:09:53 +01:00
|
|
|
pq_putmessage('I', "", 1);
|
1998-05-07 01:51:16 +02:00
|
|
|
break;
|
|
|
|
|
2005-11-03 18:11:40 +01:00
|
|
|
case DestNone:
|
|
|
|
case DestDebug:
|
|
|
|
case DestSPI:
|
|
|
|
case DestTuplestore:
|
2006-08-12 04:52:06 +02:00
|
|
|
case DestIntoRel:
|
2006-08-31 01:34:22 +02:00
|
|
|
case DestCopyOut:
|
2008-10-31 20:37:56 +01:00
|
|
|
case DestSQLFunction:
|
2013-03-04 01:23:31 +01:00
|
|
|
case DestTransientRel:
|
Glue layer to connect the executor to the shm_mq mechanism.
The shm_mq mechanism was built to send error (and notice) messages and
tuples between backends. However, shm_mq itself only deals in raw
bytes. Since commit 2bd9e412f92bc6a68f3e8bcb18e04955cc35001d, we have
had infrastructure for one message to redirect protocol messages to a
queue and for another backend to parse them and do useful things with
them. This commit introduces a somewhat analogous facility for tuples
by adding a new type of DestReceiver, DestTupleQueue, which writes
each tuple generated by a query into a shm_mq, and a new
TupleQueueFunnel facility which reads raw tuples out of the queue and
reconstructs the HeapTuple format expected by the executor.
The TupleQueueFunnel abstraction supports reading from multiple tuple
streams at the same time, but only in round-robin fashion. Someone
could imaginably want other policies, but this should be good enough
to meet our short-term needs related to parallel query, and we can
always extend it later.
This also makes one minor addition to the shm_mq API that didn'
seem worth breaking out as a separate patch.
Extracted from Amit Kapila's parallel sequential scan patch. This
code was originally written by me, and then it was revised by Amit,
and then it was revised some more by me.
2015-09-19 03:10:08 +02:00
|
|
|
case DestTupleQueue:
|
1998-05-07 01:51:16 +02:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* ----------------
|
|
|
|
* ReadyForQuery - tell dest that we are ready for a new query
|
|
|
|
*
|
2016-10-11 18:19:18 +02:00
|
|
|
* The ReadyForQuery message is sent so that the FE can tell when
|
|
|
|
* we are done processing a query string.
|
2003-04-26 22:23:00 +02:00
|
|
|
* In versions 3.0 and up, it also carries a transaction state indicator.
|
1998-05-07 01:51:16 +02:00
|
|
|
*
|
|
|
|
* Note that by flushing the stdio buffer here, we can avoid doing it
|
|
|
|
* most other places and thus reduce the number of separate packets sent.
|
|
|
|
* ----------------
|
|
|
|
*/
|
|
|
|
void
|
|
|
|
ReadyForQuery(CommandDest dest)
|
|
|
|
{
|
1997-09-07 07:04:48 +02:00
|
|
|
switch (dest)
|
|
|
|
{
|
2005-11-03 18:11:40 +01:00
|
|
|
case DestRemote:
|
|
|
|
case DestRemoteExecute:
|
2003-04-26 22:23:00 +02:00
|
|
|
if (PG_PROTOCOL_MAJOR(FrontendProtocol) >= 3)
|
|
|
|
{
|
|
|
|
StringInfoData buf;
|
|
|
|
|
|
|
|
pq_beginmessage(&buf, 'Z');
|
|
|
|
pq_sendbyte(&buf, TransactionBlockStatusCode());
|
|
|
|
pq_endmessage(&buf);
|
|
|
|
}
|
2016-10-11 18:19:18 +02:00
|
|
|
else
|
2003-04-22 02:08:07 +02:00
|
|
|
pq_putemptymessage('Z');
|
1999-01-27 01:36:28 +01:00
|
|
|
/* Flush output at end of cycle in any case. */
|
|
|
|
pq_flush();
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
|
|
|
|
2005-11-03 18:11:40 +01:00
|
|
|
case DestNone:
|
|
|
|
case DestDebug:
|
|
|
|
case DestSPI:
|
|
|
|
case DestTuplestore:
|
2006-08-12 04:52:06 +02:00
|
|
|
case DestIntoRel:
|
2006-08-31 01:34:22 +02:00
|
|
|
case DestCopyOut:
|
2008-10-31 20:37:56 +01:00
|
|
|
case DestSQLFunction:
|
2013-03-04 01:23:31 +01:00
|
|
|
case DestTransientRel:
|
Glue layer to connect the executor to the shm_mq mechanism.
The shm_mq mechanism was built to send error (and notice) messages and
tuples between backends. However, shm_mq itself only deals in raw
bytes. Since commit 2bd9e412f92bc6a68f3e8bcb18e04955cc35001d, we have
had infrastructure for one message to redirect protocol messages to a
queue and for another backend to parse them and do useful things with
them. This commit introduces a somewhat analogous facility for tuples
by adding a new type of DestReceiver, DestTupleQueue, which writes
each tuple generated by a query into a shm_mq, and a new
TupleQueueFunnel facility which reads raw tuples out of the queue and
reconstructs the HeapTuple format expected by the executor.
The TupleQueueFunnel abstraction supports reading from multiple tuple
streams at the same time, but only in round-robin fashion. Someone
could imaginably want other policies, but this should be good enough
to meet our short-term needs related to parallel query, and we can
always extend it later.
This also makes one minor addition to the shm_mq API that didn'
seem worth breaking out as a separate patch.
Extracted from Amit Kapila's parallel sequential scan patch. This
code was originally written by me, and then it was revised by Amit,
and then it was revised some more by me.
2015-09-19 03:10:08 +02:00
|
|
|
case DestTupleQueue:
|
1997-09-08 04:41:22 +02:00
|
|
|
break;
|
1996-07-09 08:22:35 +02:00
|
|
|
}
|
|
|
|
}
|