On Fri, May 13, 2022 at 6:41 PM Robert Haas wrote:
>
> On Fri, Apr 29, 2022 at 5:11 AM Bharath Rupireddy
> wrote:
> > Here's the rebased v9 patch.
>
> This seems like it has enormous overlap with the existing
> functionality that we have from log_startup_progress_interval.
>
> I think that
On Fri, May 13, 2022 at 09:10:52AM -0400, Robert Haas wrote:
> I suggest that if log_startup_progress_interval doesn't meet your
> needs here, we should try to understand why not and maybe enhance it,
> instead of adding a separate facility.
+1. AFAICT it should be possible to make the
On Tue, May 17, 2022 at 1:32 AM Bharath Rupireddy
wrote:
> In a production environment (of course with a better management of
> server logs) one can set log_wal_traffic to "high" and emit the
> required info to answer some of the customer questions like - "How far
> the server is in recovery? How
On Fri, May 13, 2022 at 6:41 PM Robert Haas wrote:
>
> On Fri, Apr 29, 2022 at 5:11 AM Bharath Rupireddy
> wrote:
> > Here's the rebased v9 patch.
>
> This seems like it has enormous overlap with the existing
> functionality that we have from log_startup_progress_interval.
>
> I think that
On Fri, Apr 29, 2022 at 5:11 AM Bharath Rupireddy
wrote:
> Here's the rebased v9 patch.
This seems like it has enormous overlap with the existing
functionality that we have from log_startup_progress_interval.
I think that facility is also better-designed than this one. It prints
out a message
On Thu, May 5, 2022 at 2:07 PM Alvaro Herrera wrote:
>
> On 2022-May-05, Bharath Rupireddy wrote:
>
> > On Fri, Apr 29, 2022 at 4:11 PM Alvaro Herrera
> > wrote:
> > >
> > > Did we ever consider the idea of using a new pg_stat_wal_activity_progress
> > > view or something like that, using the
On 2022-May-05, Bharath Rupireddy wrote:
> On Fri, Apr 29, 2022 at 4:11 PM Alvaro Herrera
> wrote:
> >
> > Did we ever consider the idea of using a new pg_stat_wal_activity_progress
> > view or something like that, using the backend_progress.c functionality?
> > I don't see it mentioned in the
On Fri, Apr 29, 2022 at 4:11 PM Alvaro Herrera wrote:
>
> Did we ever consider the idea of using a new pg_stat_wal_activity_progress
> view or something like that, using the backend_progress.c functionality?
> I don't see it mentioned in the thread.
IMO, progress reporting works well on a
Did we ever consider the idea of using a new pg_stat_wal_activity_progress
view or something like that, using the backend_progress.c functionality?
I don't see it mentioned in the thread.
It's not an *exact* fit, since this is not about one "command" being
executed by a "backend", but it seems a
On Sun, Feb 27, 2022 at 12:50 PM Bharath Rupireddy
wrote:
>
> On Wed, Dec 29, 2021 at 6:50 AM Bharath Rupireddy
> wrote:
> >
> > On Thu, Dec 9, 2021 at 9:28 PM Alvaro Herrera
> > wrote:
> > >
> > > Maybe some tunable like
> > > log_wal_traffic = { none, medium, high }
> > > where "none" is
On Wed, Dec 29, 2021 at 6:50 AM Bharath Rupireddy
wrote:
>
> On Thu, Dec 9, 2021 at 9:28 PM Alvaro Herrera wrote:
> >
> > Maybe some tunable like
> > log_wal_traffic = { none, medium, high }
> > where "none" is current behavior of no noise, "medium" gets (say) once
> > every 256 segments (e.g.,
On Thu, Dec 9, 2021 at 9:28 PM Alvaro Herrera wrote:
>
> Maybe some tunable like
> log_wal_traffic = { none, medium, high }
> where "none" is current behavior of no noise, "medium" gets (say) once
> every 256 segments (e.g., when going from XFF to (X+1)00), "high" gets
> you one message per
On Fri, Dec 24, 2021 at 08:04:08PM +0530, Bharath Rupireddy wrote:
> On Fri, Dec 24, 2021 at 7:19 PM Justin Pryzby wrote:
> > On Sun, Dec 12, 2021 at 06:08:05PM +0530, Bharath Rupireddy wrote:
> > > Another idea could be to use the infrastructure laid out by the commit
> > > 9ce346e [1]. With
On Fri, Dec 24, 2021 at 7:19 PM Justin Pryzby wrote:
>
> On Sun, Dec 12, 2021 at 06:08:05PM +0530, Bharath Rupireddy wrote:
> > Another idea could be to use the infrastructure laid out by the commit
> > 9ce346e [1]. With ereport_startup_progress, we can emit the LOGs(of
> > current recovering WAL
On Sun, Dec 12, 2021 at 06:08:05PM +0530, Bharath Rupireddy wrote:
> Another idea could be to use the infrastructure laid out by the commit
> 9ce346e [1]. With ereport_startup_progress, we can emit the LOGs(of
> current recovering WAL file) for every log_startup_progress_interval
>
On Thu, Dec 9, 2021 at 9:28 PM Alvaro Herrera wrote:
>
> On 2021-Dec-09, Bharath Rupireddy wrote:
>
> > On Thu, Dec 9, 2021 at 6:00 PM Alvaro Herrera
> > wrote:
> > >
> > > On 2021-Dec-09, Bharath Rupireddy wrote:
> > >
> > > > I just want to call this out: an insertion of 10 million rows in
On 2021-Dec-09, Bharath Rupireddy wrote:
> On Thu, Dec 9, 2021 at 6:00 PM Alvaro Herrera wrote:
> >
> > On 2021-Dec-09, Bharath Rupireddy wrote:
> >
> > > I just want to call this out: an insertion of 10 million rows in the
> > > primary generates a bunch of messages in the standby [1] within 40
On Thu, Dec 9, 2021 at 6:00 PM Alvaro Herrera wrote:
>
> On 2021-Dec-09, Bharath Rupireddy wrote:
>
> > I just want to call this out: an insertion of 10 million rows in the
> > primary generates a bunch of messages in the standby [1] within 40 sec
> > (size of the standby server log grows by 5K).
On 2021-Dec-09, Bharath Rupireddy wrote:
> I just want to call this out: an insertion of 10 million rows in the
> primary generates a bunch of messages in the standby [1] within 40 sec
> (size of the standby server log grows by 5K).
Hmm, that does sound excessive to me in terms of log bloat
On Thu, Dec 9, 2021 at 11:28 AM Bharath Rupireddy
wrote:
>
> On Thu, Dec 9, 2021 at 7:56 AM Michael Paquier wrote:
> >
> > On Wed, Dec 08, 2021 at 04:57:49PM +0530, Bharath Rupireddy wrote:
> > > Done in the attached v5 patch.
> >
> > Thanks for the new version. FWIW, as the information logged
On Thu, Dec 9, 2021 at 7:56 AM Michael Paquier wrote:
>
> On Wed, Dec 08, 2021 at 04:57:49PM +0530, Bharath Rupireddy wrote:
> > Done in the attached v5 patch.
>
> Thanks for the new version. FWIW, as the information logged when
> recovering a WAL segment from the local pg_wal could be rather
>
On Wed, Dec 08, 2021 at 04:57:49PM +0530, Bharath Rupireddy wrote:
> Done in the attached v5 patch.
Thanks for the new version. FWIW, as the information logged when
recovering a WAL segment from the local pg_wal could be rather
confusing at bootstrap phase, I would suggest to simplify things as
On Wed, Dec 8, 2021 at 2:08 PM Michael Paquier wrote:
> > Do you want me to add "received from stream" in general?
>
> "from stream" would be fine, IMHO.
Done in the attached v5 patch.
> > How about we invent a new GUC log_recovery, with default set to false,
> > similar to log_checkpoints?
On Wed, Dec 08, 2021 at 02:00:12PM +0530, Bharath Rupireddy wrote:
> For standby, "received from primary" makes sense. For cascading
> standby too it makes sense because the standby still acts as primary
> for cascading standby, no? And we don't distinguish any other existing
> messages for a
On Wed, Dec 8, 2021 at 12:52 PM Michael Paquier wrote:
>
> On Wed, Dec 08, 2021 at 10:47:57AM +0530, Bharath Rupireddy wrote:
> > Thanks for taking a look at the patch. How about the attached v4?
> >
> > I added a CF entry - https://commitfest.postgresql.org/36/3443/
>
> + else if (source
On Wed, Dec 08, 2021 at 10:47:57AM +0530, Bharath Rupireddy wrote:
> Thanks for taking a look at the patch. How about the attached v4?
>
> I added a CF entry - https://commitfest.postgresql.org/36/3443/
+ else if (source == XLOG_FROM_STREAM)
+ ereport(LOG,
+
On Wed, Dec 8, 2021 at 10:05 AM Michael Paquier wrote:
>
> On Tue, Dec 07, 2021 at 06:28:24PM +0530, Bharath Rupireddy wrote:
> > Upon thinking further, having at least the messages at LOG level [1]
> > would be helpful to know what's happening with the system while in
> > recovery. Although
On Tue, Dec 07, 2021 at 06:28:24PM +0530, Bharath Rupireddy wrote:
> Upon thinking further, having at least the messages at LOG level [1]
> would be helpful to know what's happening with the system while in
> recovery. Although these messages at LOG level seem to be filling up
> the server logs,
On Wed, Nov 17, 2021 at 8:01 AM Michael Paquier wrote:
>
> On Tue, Nov 16, 2021 at 01:26:49PM -0300, Alvaro Herrera wrote:
> > My opinion is that adding these things willy-nilly is not a solution to
> > any actual problem. Adding a few additional log lines that are
> > low-volume at DEBUG1 might
On Tue, Nov 16, 2021 at 01:26:49PM -0300, Alvaro Herrera wrote:
> My opinion is that adding these things willy-nilly is not a solution to
> any actual problem. Adding a few additional log lines that are
> low-volume at DEBUG1 might be useful, but below that (DEBUG2 etc) it's
> not good for
On 2021-Nov-16, Bossart, Nathan wrote:
> On 11/15/21, 7:14 PM, "Michael Paquier" wrote:
> > + ereport(DEBUG1,
> > + (errmsg_internal("streaming %X/%X",
> > +
> > LSN_FORMAT_ARGS(sentPtr;
> > Anyway, those
On 11/15/21, 7:14 PM, "Michael Paquier" wrote:
> + ereport(DEBUG1,
> + (errmsg_internal("streaming %X/%X",
> +
> LSN_FORMAT_ARGS(sentPtr;
> Anyway, those two ones are going to make the logs much more noisy,
On Mon, Nov 15, 2021 at 10:36:09PM +, Bossart, Nathan wrote:
> +ereport(DEBUG1,
> +(errmsg_internal("executing archive command \"%s\" for archving
> %s",
> + xlogarchcmd, xlog)));
>
> I wonder if it's necessary to include the "for archiving" part
On 11/14/21, 4:18 AM, "Bharath Rupireddy"
wrote:
> Thanks. Attaching the v2 to avoid that by directly using the message
> in ereport instead of activitymsg.
+ereport(DEBUG1,
+(errmsg_internal("waiting for %s", xlogfname)));
As a general comment, I think we
On Sat, Nov 13, 2021 at 9:04 PM Alvaro Herrera
wrote:
>
> A bunch of these now execute snprintf()s unnecessarily. I think these
> should be made conditional on message_level_is_interesting(DEBUG1) to
> avoid that overhead.
Thanks. Attaching the v2 to avoid that by directly using the message in
A bunch of these now execute snprintf()s unnecessarily. I think these
should be made conditional on message_level_is_interesting(DEBUG1) to
avoid that overhead.
--
Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/
"You're _really_ hosed if the person doing the hiring
On Thu, Nov 11, 2021 at 8:41 PM Bossart, Nathan wrote:
> > I'm not sure whether it is okay to do the following, for every of the
> > activitymsg, before the command execution, we have an elog(DEBUG1
> > message and after the command execution another elog(DEBUG1 message.
>
> The general idea
On Thu, Nov 11, 2021 at 6:07 PM Alvaro Herrera
wrote:
> On 2021-Nov-10, Bossart, Nathan wrote:
>
> > On 11/10/21, 9:43 AM, "Bharath Rupireddy" <
> bharath.rupireddyforpostg...@gmail.com> wrote:
> > > As discussed in [1], isn't it a better idea to add some of activity
> > > messages [2] such as
On Thu, Nov 11, 2021 at 03:18:16PM +, Bossart, Nathan wrote:
> On 11/11/21, 4:38 AM, "Alvaro Herrera" wrote:
> > Yeah. If we had some sort of ring buffer in which to store these
> > messages, the user could examine them through a view; they would still
> > be accessible in a running server,
On Thu, Nov 11, 2021, at 2:50 AM, Bharath Rupireddy wrote:
> But for the snprintf(activitymsg, sizeof(activitymsg), "archiving %s",
> xlog); we have elog(DEBUG1, "archived write-ahead log file \"%s\"",
> xlog); after the archiving command. It is also good to have a similar
> debug message before
On 11/11/21, 4:38 AM, "Alvaro Herrera" wrote:
> Yeah. If we had some sort of ring buffer in which to store these
> messages, the user could examine them through a view; they would still
> be accessible in a running server, but they would not be written to the
> server log.
That's an interesting
On 11/10/21, 9:51 PM, "Bharath Rupireddy"
wrote:
> But for the snprintf(activitymsg, sizeof(activitymsg), "archiving %s",
> xlog); we have elog(DEBUG1, "archived write-ahead log file \"%s\"",
> xlog); after the archiving command. It is also good to have a similar
> debug message before archive
On 2021-Nov-10, Bossart, Nathan wrote:
> On 11/10/21, 9:43 AM, "Bharath Rupireddy"
> wrote:
> > As discussed in [1], isn't it a better idea to add some of activity
> > messages [2] such as recovery, archive, backup, streaming etc. to
> > server logs at LOG level?
> I think this would make the
On Thu, Nov 11, 2021 at 1:40 AM Euler Taveira wrote:
>
> On Wed, Nov 10, 2021, at 2:38 PM, Bharath Rupireddy wrote:
>
> As discussed in [1], isn't it a better idea to add some of activity
> messages [2] such as recovery, archive, backup, streaming etc. to
> server logs at LOG level? They are
On Thu, Nov 11, 2021 at 12:01 AM Bossart, Nathan wrote:
>
> On 11/10/21, 9:43 AM, "Bharath Rupireddy"
> wrote:
> > As discussed in [1], isn't it a better idea to add some of activity
> > messages [2] such as recovery, archive, backup, streaming etc. to
> > server logs at LOG level? They are
On Wed, Nov 10, 2021, at 2:38 PM, Bharath Rupireddy wrote:
> As discussed in [1], isn't it a better idea to add some of activity
> messages [2] such as recovery, archive, backup, streaming etc. to
> server logs at LOG level? They are currently being set into ps display
> which is good if the
On 11/10/21, 9:43 AM, "Bharath Rupireddy"
wrote:
> As discussed in [1], isn't it a better idea to add some of activity
> messages [2] such as recovery, archive, backup, streaming etc. to
> server logs at LOG level? They are currently being set into ps display
> which is good if the postgres is
Hi,
As discussed in [1], isn't it a better idea to add some of activity
messages [2] such as recovery, archive, backup, streaming etc. to
server logs at LOG level? They are currently being set into ps display
which is good if the postgres is being run on a standalone box/VM
where users can see
48 matches
Mail list logo
