1996-07-09 02:22:35 -04:00
|
|
|
/*-------------------------------------------------------------------------
|
|
|
|
|
*
|
1999-02-13 18:22:53 -05:00
|
|
|
* dest.h
|
2002-02-27 14:36:13 -05:00
|
|
|
* support for communication destinations
|
|
|
|
|
*
|
2006-08-11 22:52:06 -04:00
|
|
|
* Whenever the backend executes a query that returns tuples, the results
|
|
|
|
|
* have to go someplace. For example:
|
1996-07-09 02:22:35 -04:00
|
|
|
*
|
|
|
|
|
* - stdout is the destination only when we are running a
|
2002-02-27 14:36:13 -05:00
|
|
|
* standalone backend (no postmaster) and are returning results
|
2000-07-07 23:04:41 -04:00
|
|
|
* back to an interactive user.
|
1996-07-09 02:22:35 -04:00
|
|
|
*
|
2000-07-07 23:04:41 -04:00
|
|
|
* - a remote process is the destination when we are
|
1996-07-09 02:22:35 -04:00
|
|
|
* running a backend with a frontend and the frontend executes
|
|
|
|
|
* PQexec() or PQfn(). In this case, the results are sent
|
2000-07-07 23:04:41 -04:00
|
|
|
* to the frontend via the functions in backend/libpq.
|
1997-09-07 01:04:48 -04:00
|
|
|
*
|
2005-11-03 12:11:40 -05:00
|
|
|
* - DestNone is the destination when the system executes
|
2002-02-27 14:36:13 -05:00
|
|
|
* a query internally. The results are discarded.
|
1996-07-09 02:22:35 -04:00
|
|
|
*
|
1999-01-26 19:36:28 -05:00
|
|
|
* dest.c defines three functions that implement destination management:
|
|
|
|
|
*
|
2002-02-27 14:36:13 -05:00
|
|
|
* BeginCommand: initialize the destination at start of command.
|
2003-05-06 16:26:28 -04:00
|
|
|
* CreateDestReceiver: return a pointer to a struct of destination-specific
|
1999-01-26 19:36:28 -05:00
|
|
|
* receiver functions.
|
2002-02-27 14:36:13 -05:00
|
|
|
* EndCommand: clean up the destination at end of command.
|
|
|
|
|
*
|
|
|
|
|
* BeginCommand/EndCommand are executed once per received SQL query.
|
|
|
|
|
*
|
2003-05-06 16:26:28 -04:00
|
|
|
* CreateDestReceiver returns a receiver object appropriate to the specified
|
|
|
|
|
* destination. The executor, as well as utility statements that can return
|
|
|
|
|
* tuples, are passed the resulting DestReceiver* pointer. Each executor run
|
2003-08-06 13:46:46 -04:00
|
|
|
* or utility execution calls the receiver's rStartup method, then the
|
2005-03-16 16:38:10 -05:00
|
|
|
* receiveSlot method (zero or more times), then the rShutdown method.
|
2003-05-06 16:26:28 -04:00
|
|
|
* The same receiver object may be re-used multiple times; eventually it is
|
2003-08-06 13:46:46 -04:00
|
|
|
* destroyed by calling its rDestroy method.
|
1999-01-26 19:36:28 -05:00
|
|
|
*
|
2008-11-30 15:51:25 -05:00
|
|
|
* In some cases, receiver objects require additional parameters that must
|
|
|
|
|
* be passed to them after calling CreateDestReceiver. Since the set of
|
|
|
|
|
* parameters varies for different receiver types, this is not handled by
|
|
|
|
|
* this module, but by direct calls from the calling code to receiver type
|
|
|
|
|
* specific functions.
|
|
|
|
|
*
|
2003-05-06 16:26:28 -04:00
|
|
|
* The DestReceiver object returned by CreateDestReceiver may be a statically
|
|
|
|
|
* allocated object (for destination types that require no local state),
|
2003-08-06 13:46:46 -04:00
|
|
|
* in which case rDestroy is a no-op. Alternatively it can be a palloc'd
|
2003-05-06 16:26:28 -04:00
|
|
|
* object that has DestReceiver as its first field and contains additional
|
|
|
|
|
* fields (see printtup.c for an example). These additional fields are then
|
|
|
|
|
* accessible to the DestReceiver functions by casting the DestReceiver*
|
2003-08-06 13:46:46 -04:00
|
|
|
* pointer passed to them. The palloc'd object is pfree'd by the rDestroy
|
2003-05-06 16:26:28 -04:00
|
|
|
* method. Note that the caller of CreateDestReceiver should take care to
|
|
|
|
|
* do so in a memory context that is long-lived enough for the receiver
|
|
|
|
|
* object not to disappear while still needed.
|
|
|
|
|
*
|
|
|
|
|
* Special provision: None_Receiver is a permanently available receiver
|
2005-11-03 12:11:40 -05:00
|
|
|
* object for the DestNone destination. This avoids useless creation/destroy
|
2003-05-06 16:26:28 -04:00
|
|
|
* calls in portal and cursor manipulations.
|
1999-01-26 19:36:28 -05:00
|
|
|
*
|
1996-07-09 02:22:35 -04:00
|
|
|
*
|
2022-01-07 19:04:57 -05:00
|
|
|
* Portions Copyright (c) 1996-2022, PostgreSQL Global Development Group
|
2000-01-26 00:58:53 -05:00
|
|
|
* Portions Copyright (c) 1994, Regents of the University of California
|
1996-07-09 02:22:35 -04:00
|
|
|
*
|
2010-09-20 16:08:53 -04:00
|
|
|
* src/include/tcop/dest.h
|
1996-07-09 02:22:35 -04:00
|
|
|
*
|
|
|
|
|
*-------------------------------------------------------------------------
|
|
|
|
|
*/
|
|
|
|
|
#ifndef DEST_H
|
|
|
|
|
#define DEST_H
|
|
|
|
|
|
2005-03-16 16:38:10 -05:00
|
|
|
#include "executor/tuptable.h"
|
2020-03-02 16:19:51 -05:00
|
|
|
#include "tcop/cmdtag.h"
|
1996-07-09 02:22:35 -04:00
|
|
|
|
2002-02-26 17:47:12 -05:00
|
|
|
|
|
|
|
|
/* buffer size to use for command completion tags */
|
|
|
|
|
#define COMPLETION_TAG_BUFSIZE 64
|
|
|
|
|
|
|
|
|
|
|
1996-07-09 02:22:35 -04:00
|
|
|
/* ----------------
|
1999-01-26 19:36:28 -05:00
|
|
|
* CommandDest is a simplistic means of identifying the desired
|
|
|
|
|
* destination. Someday this will probably need to be improved.
|
2003-05-04 20:44:56 -04:00
|
|
|
*
|
2005-11-03 12:11:40 -05:00
|
|
|
* Note: only the values DestNone, DestDebug, DestRemote are legal for the
|
|
|
|
|
* global variable whereToSendOutput. The other values may be used
|
2003-05-04 20:44:56 -04:00
|
|
|
* as the destination for individual commands.
|
1996-07-09 02:22:35 -04:00
|
|
|
* ----------------
|
|
|
|
|
*/
|
|
|
|
|
typedef enum
|
|
|
|
|
{
|
2005-11-03 12:11:40 -05:00
|
|
|
DestNone, /* results are discarded */
|
|
|
|
|
DestDebug, /* results go to debugging output */
|
|
|
|
|
DestRemote, /* results sent to frontend process */
|
|
|
|
|
DestRemoteExecute, /* sent to frontend, in Execute command */
|
2017-01-24 16:53:56 -05:00
|
|
|
DestRemoteSimple, /* sent to frontend, w/no catalog access */
|
2005-11-03 12:11:40 -05:00
|
|
|
DestSPI, /* results sent to SPI manager */
|
2006-08-11 22:52:06 -04:00
|
|
|
DestTuplestore, /* results sent to Tuplestore */
|
2006-08-30 19:34:22 -04:00
|
|
|
DestIntoRel, /* results sent to relation (SELECT INTO) */
|
2008-10-31 15:37:56 -04:00
|
|
|
DestCopyOut, /* results sent to COPY TO code */
|
2013-03-03 19:23:31 -05:00
|
|
|
DestSQLFunction, /* results sent to SQL-language func mgr */
|
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-18 21:10:08 -04:00
|
|
|
DestTransientRel, /* results sent to transient relation */
|
|
|
|
|
DestTupleQueue /* results sent to tuple queue */
|
1996-07-09 02:22:35 -04:00
|
|
|
} CommandDest;
|
|
|
|
|
|
1999-01-26 19:36:28 -05:00
|
|
|
/* ----------------
|
|
|
|
|
* DestReceiver is a base type for destination-specific local state.
|
|
|
|
|
* In the simplest cases, there is no state info, just the function
|
|
|
|
|
* pointers that the executor must call.
|
2003-05-06 16:26:28 -04:00
|
|
|
*
|
2005-03-16 16:38:10 -05:00
|
|
|
* Note: the receiveSlot routine must be passed a slot containing a TupleDesc
|
2016-06-06 14:52:58 -04:00
|
|
|
* identical to the one given to the rStartup routine. It returns bool where
|
|
|
|
|
* a "true" value means "continue processing" and a "false" value means
|
|
|
|
|
* "stop early, just as if we'd reached the end of the scan".
|
1999-01-26 19:36:28 -05:00
|
|
|
* ----------------
|
|
|
|
|
*/
|
|
|
|
|
typedef struct _DestReceiver DestReceiver;
|
1996-07-09 02:22:35 -04:00
|
|
|
|
1999-01-26 19:36:28 -05:00
|
|
|
struct _DestReceiver
|
|
|
|
|
{
|
|
|
|
|
/* Called for each tuple to be output: */
|
2016-06-06 14:52:58 -04:00
|
|
|
bool (*receiveSlot) (TupleTableSlot *slot,
|
2005-03-16 16:38:10 -05:00
|
|
|
DestReceiver *self);
|
2003-05-06 16:26:28 -04:00
|
|
|
/* Per-executor-run initialization and shutdown: */
|
2003-08-06 13:46:46 -04:00
|
|
|
void (*rStartup) (DestReceiver *self,
|
2003-05-08 14:16:37 -04:00
|
|
|
int operation,
|
|
|
|
|
TupleDesc typeinfo);
|
2003-08-06 13:46:46 -04:00
|
|
|
void (*rShutdown) (DestReceiver *self);
|
2003-05-06 16:26:28 -04:00
|
|
|
/* Destroy the receiver object itself (if dynamically allocated) */
|
2003-08-06 13:46:46 -04:00
|
|
|
void (*rDestroy) (DestReceiver *self);
|
2003-05-06 16:26:28 -04:00
|
|
|
/* CommandDest code for this receiver */
|
|
|
|
|
CommandDest mydest;
|
1999-01-26 19:36:28 -05:00
|
|
|
/* Private fields might appear beyond this point... */
|
|
|
|
|
};
|
1996-07-09 02:22:35 -04:00
|
|
|
|
2017-12-05 09:23:57 -05:00
|
|
|
extern PGDLLIMPORT DestReceiver *None_Receiver; /* permanent receiver for
|
|
|
|
|
* DestNone */
|
2003-05-06 16:26:28 -04:00
|
|
|
|
1999-01-26 19:36:28 -05:00
|
|
|
/* The primary destination management functions */
|
1996-07-09 02:22:35 -04:00
|
|
|
|
2020-03-02 16:19:51 -05:00
|
|
|
extern void BeginCommand(CommandTag commandTag, CommandDest dest);
|
2008-11-30 15:51:25 -05:00
|
|
|
extern DestReceiver *CreateDestReceiver(CommandDest dest);
|
2020-03-02 16:19:51 -05:00
|
|
|
extern void EndCommand(const QueryCompletion *qc, CommandDest dest,
|
|
|
|
|
bool force_undecorated_output);
|
Fix bogus completion tag usage in walsender
Since commit fd5942c18f97 (2012, 9.3-era), walsender has been sending
completion tags for certain replication commands twice -- and they're
not even consistent. Apparently neither libpq nor JDBC have a problem
with it, but it's not kosher. Fix by remove the EndCommand() call in
the common code path for them all, and inserting specific calls to
EndReplicationCommand() specifically in those places where it's needed.
EndReplicationCommand() is a new simple function to send the completion
tag for replication commands. Do this instead of sending a generic
SELECT completion tag for them all, which was also pretty bogus (if
innocuous). While at it, change StartReplication() to use
EndReplicationCommand() instead of pg_puttextmessage().
In commit 2f9661311b83, I failed to realize that replication commands
are not close-enough kin of regular SQL commands, so the
DROP_REPLICATION_SLOT tag I added is undeserved and a type pun. Take it
out.
Backpatch to 13, where the latter commit appeared. The duplicate tag
has been sent since 9.3, but since nothing is broken, it doesn't seem
worth fixing.
Per complaints from Tom Lane.
Discussion: https://postgr.es/m/1347966.1600195735@sss.pgh.pa.us
2020-09-16 12:04:38 -04:00
|
|
|
extern void EndReplicationCommand(const char *commandTag);
|
1999-01-26 19:36:28 -05:00
|
|
|
|
|
|
|
|
/* Additional functions that go with destination management, more or less. */
|
|
|
|
|
|
1996-07-09 02:22:35 -04:00
|
|
|
extern void NullCommand(CommandDest dest);
|
1998-05-06 19:51:16 -04:00
|
|
|
extern void ReadyForQuery(CommandDest dest);
|
2001-10-28 01:26:15 -05:00
|
|
|
|
1996-07-09 02:22:35 -04:00
|
|
|
#endif /* DEST_H */
|