On Wed, Aug 17, 2022 at 8:44 PM Robert Haas wrote:
>
> Well, I don't agree that either of the proposed new uses of this
> infrastructure are the right way to solve the problems in question, so
> worrying about how to name the GUCs when we have a bunch of uses of
> this infrastructure seems to me t
On Wed, Aug 17, 2022 at 4:30 AM Bharath Rupireddy
wrote:
> As I explained upthread [1], I'd vote for a single GUC at the entire
> server level. If the users/customers request per-process or
> per-operation progress report GUCs, we can then consider it.
Well, I don't agree that either of the propo
On Wed, Aug 17, 2022 at 2:45 AM Nathan Bossart wrote:
>
> On Wed, Aug 10, 2022 at 11:00:20AM -0400, Robert Haas wrote:
> > Maybe the checkpointer is a better candidate, but somehow I feel that
> > we can't consider this sort of thing separate from the existing
> > progress reporting that checkpoin
On Wed, Aug 10, 2022 at 6:21 PM Nitin Jadhav
wrote:
>
> Given two options, option-1 is to use a single GUC across all kind of
> log running operations and option-2 is to use multiple GUCs (one for
> each kind of long running operations), I go with option-1 because if a
> user is interested to see
On Wed, Aug 10, 2022 at 11:00:20AM -0400, Robert Haas wrote:
> Maybe the checkpointer is a better candidate, but somehow I feel that
> we can't consider this sort of thing separate from the existing
> progress reporting that checkpointer already does. Perhaps we need to
> think of changing or impro
On Tue, Aug 9, 2022 at 11:54 AM Bharath Rupireddy
wrote:
> I'm attaching 0002 for reporting removal of temp files and temp
> relation files by postmaster.
>
> If this looks okay, I can code 0003 for reporting processing of
> snapshot, mapping and old WAL files by checkpointer.
I think that someon
> > > Here's an attempt to generalize the ereport_startup_progress
> > > infrastructure. The attached v1 patch places the code in elog.c/.h,
> > > renames associated functions and variables, something like
> > > ereport_startup_progress to ereport_progress,
> > > log_startup_progress_interval to lo
On Tue, Aug 9, 2022 at 6:05 PM Robert Haas wrote:
>
> On Mon, Aug 8, 2022 at 12:29 AM Bharath Rupireddy
> wrote:
> > Here's v2 patch, passing progress report interval as an input to
> > begin_progress_report_phase() so that the processes can use their own
> > intervals(hard-coded or GUC) if they
On Mon, Aug 8, 2022 at 12:29 AM Bharath Rupireddy
wrote:
> Here's v2 patch, passing progress report interval as an input to
> begin_progress_report_phase() so that the processes can use their own
> intervals(hard-coded or GUC) if they wish to not use the generic GUC
> log_progress_report_interval.
On Thu, Aug 4, 2022 at 9:57 AM Bharath Rupireddy
wrote:
>
> On Wed, Aug 3, 2022 at 12:11 AM Robert Haas wrote:
> >
> > On Tue, Aug 2, 2022 at 3:25 AM Bharath Rupireddy
> > wrote:
> > > ereport_startup_progress infrastructure added by commit 9ce346e [1]
> > > will be super-useful for reporting pr
On Wed, Aug 3, 2022 at 12:11 AM Robert Haas wrote:
>
> On Tue, Aug 2, 2022 at 3:25 AM Bharath Rupireddy
> wrote:
> > ereport_startup_progress infrastructure added by commit 9ce346e [1]
> > will be super-useful for reporting progress of any long-running server
> > operations, not just the startup
On Tue, Aug 2, 2022 at 3:25 AM Bharath Rupireddy
wrote:
> ereport_startup_progress infrastructure added by commit 9ce346e [1]
> will be super-useful for reporting progress of any long-running server
> operations, not just the startup process operations. For instance,
> postmaster can use it for re
Hi,
ereport_startup_progress infrastructure added by commit 9ce346e [1]
will be super-useful for reporting progress of any long-running server
operations, not just the startup process operations. For instance,
postmaster can use it for reporting progress of temp file and temp
relation file removal
13 matches
Mail list logo
