public inbox for [email protected]  
help / color / mirror / Atom feed
[PATCH 2/6] 0001 review
3+ messages / 3 participants
[nested] [flat]

* [PATCH 2/6] 0001 review
@ 2021-02-15 15:26  Tomas Vondra <[email protected]>
  0 siblings, 0 replies; 3+ messages in thread

From: Tomas Vondra @ 2021-02-15 15:26 UTC (permalink / raw)

---
 doc/src/sgml/monitoring.sgml    | 2 +-
 src/backend/commands/copyfrom.c | 1 +
 src/backend/commands/copyto.c   | 2 ++
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index 3c39c82f1a..c5048fefd4 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -6561,7 +6561,7 @@ SELECT pg_stat_get_backend_pid(s.backendid) AS pid,
       <para>
        The io target that the data is read from or written to: 
        <literal>FILE</literal>, <literal>PROGRAM</literal>, 
-       <literal>STDIO</literal> (for COPY FROM STDIN and COPY TO STDOUT),
+       <literal>STDIO</literal> (for <command>COPY FROM STDIN</command> and <command>COPY TO STDOUT</command>),
        or <literal>CALLBACK</literal> (used in the table synchronization
        background worker).
       </para></entry>
diff --git a/src/backend/commands/copyfrom.c b/src/backend/commands/copyfrom.c
index c3610eb67e..d98f447cf5 100644
--- a/src/backend/commands/copyfrom.c
+++ b/src/backend/commands/copyfrom.c
@@ -1508,6 +1508,7 @@ BeginCopyFrom(ParseState *pstate,
 		ReceiveCopyBinaryHeader(cstate);
 	}
 
+	/* XXX this block seems weird */
 	{
 		int64 io_target;
 		switch (cstate->copy_src)
diff --git a/src/backend/commands/copyto.c b/src/backend/commands/copyto.c
index 42c4a828df..4b76bf5ef6 100644
--- a/src/backend/commands/copyto.c
+++ b/src/backend/commands/copyto.c
@@ -772,6 +772,8 @@ BeginCopyTo(ParseState *pstate,
 	/* initialize progress */
 	pgstat_progress_start_command(PROGRESS_COMMAND_COPY,
 								  cstate->rel ? RelationGetRelid(cstate->rel) : InvalidOid);
+
+	/* XXX this too */
 	{
 		const int progress_index[] = {
 			PROGRESS_COPY_COMMAND,
-- 
2.26.2


--------------DA8D60BF026F7ACE69A9AEE5
Content-Type: text/x-patch; charset=UTF-8;
 name="v7-0003-Add-backlinks-to-progress-reporting-documentation.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename*0="v7-0003-Add-backlinks-to-progress-reporting-documentation.pa";
 filename*1="tch"



^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: Propagate sanity checks of ProcessUtility() to standard_ProcessUtility()?
@ 2024-02-29 08:10  jian he <[email protected]>
  0 siblings, 1 reply; 3+ messages in thread

From: jian he @ 2024-02-29 08:10 UTC (permalink / raw)
  To: Michael Paquier <[email protected]>; +Cc: Postgres hackers <[email protected]>

On Thu, Feb 29, 2024 at 3:21 PM Michael Paquier <[email protected]> wrote:
>
> Hi all,
>
> It's been brought to me that an extension may finish by breaking the
> assumptions ProcessUtility() relies on when calling
> standard_ProcessUtility(), causing breakages when passing down data to
> cascading utility hooks.
>
> Isn't the state of the arguments given something we should check not
> only in the main entry point ProcessUtility() but also in
> standard_ProcessUtility(), to prevent issues if an extension
> incorrectly manipulates the arguments it needs to pass down to other
> modules that use the utility hook, like using a NULL query string?
>
> See the attached for the idea.

why not just shovel these to standard_ProcessUtility.
so ProcessUtility will looking consistent with (in format)
 * ExecutorStart()
 * ExecutorRun()
 * ExecutorFinish()
 * ExecutorEnd()






^ permalink  raw  reply  [nested|flat] 3+ messages in thread

* Re: Propagate sanity checks of ProcessUtility() to standard_ProcessUtility()?
@ 2024-03-01 02:05  Michael Paquier <[email protected]>
  parent: jian he <[email protected]>
  0 siblings, 0 replies; 3+ messages in thread

From: Michael Paquier @ 2024-03-01 02:05 UTC (permalink / raw)
  To: jian he <[email protected]>; +Cc: Postgres hackers <[email protected]>

On Thu, Feb 29, 2024 at 04:10:26PM +0800, jian he wrote:
> why not just shovel these to standard_ProcessUtility.
> so ProcessUtility will looking consistent with (in format)
>  * ExecutorStart()
>  * ExecutorRun()
>  * ExecutorFinish()
>  * ExecutorEnd()

That's one of the points of the change: checking that only in
standard_ProcessUtility() may not be sufficient for utility hooks that
don't call standard_ProcessUtility(), so you'd stil want one in
ProcessUtility().
--
Michael


Attachments:

  [application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
  download

^ permalink  raw  reply  [nested|flat] 3+ messages in thread


end of thread, other threads:[~2024-03-01 02:05 UTC | newest]

Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-02-15 15:26 [PATCH 2/6] 0001 review Tomas Vondra <[email protected]>
2024-02-29 08:10 Re: Propagate sanity checks of ProcessUtility() to standard_ProcessUtility()? jian he <[email protected]>
2024-03-01 02:05 ` Re: Propagate sanity checks of ProcessUtility() to standard_ProcessUtility()? Michael Paquier <[email protected]>

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox