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
12 matches
Mail list logo
