public inbox for [email protected]  

help / color / mirror / Atom feed

From: Antonin Houska <[email protected]>
To: Sami Imseih <[email protected]>
Cc: [email protected]
Subject: Re: Conflicting updates of command progress
Date: Wed, 23 Apr 2025 12:26:12 +0200
Message-ID: <17632.1745403972@localhost> (raw)
In-Reply-To: <CAA5RZ0s_Hta6PWDwY9Lf-c+14F+C13BK2ax=B6R7bmDNhN6xdQ@mail.gmail.com>
References: <117147.1744380740@localhost>
	<CAA5RZ0s_Hta6PWDwY9Lf-c+14F+C13BK2ax=B6R7bmDNhN6xdQ@mail.gmail.com>

Sami Imseih <[email protected]> wrote:

> > While working on [1] I realized that some field of pg_stat_progress_cluste has
> > weird value.
> 
> Is there a repro that you can share that shows the weird values? It sounds like
> the repro is on top of [1]. Is that right?

Yes.

> > AFAICS the current design does not consider that one progress-reporting
> > command can be called by another one.
> 
> pgstat_progress_start_command should only be called once by the entry
> point for the
> command. In theory, we could end up in a situation where start_command
> is called multiple times during the same top-level command;

Not only in theory - it actually happens when CLUSTER is rebuilding indexes.

> > Not sure what the correct fix is. We can
> > either ignore update requests from the "nested" commands, or display the
> 
> There is a pattern where we do
> 
> ```
> if (progress)
>       pgstat_progress_update_param
> ```
> 
> cluster_rel can pass down a flag to index_build or others that update progress
> to not report progress. Therefore, only the top level command is
> updating progress.
> what do you think?

That's a possible approach. However, if the index build takes long time in the
CLUSTER case, the user will probably be interested in details about the index
build.

The other approach is that we report only on the index build, but in that case
the interesting row of pg_stat_progress_cluster would disappear
temporarily. That might also be confusing.

Ideally we should report on all the commands in progress, but that is not
trivial to implement.

> [1] https://commitfest.postgresql.org/patch/5117/

-- 
Antonin Houska
Web: https://www.cybertec-postgresql.com

view thread (10+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected]
  Subject: Re: Conflicting updates of command progress
  In-Reply-To: <17632.1745403972@localhost>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

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