Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display

From: Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: add recovery, backup, archive, streaming etc. activity messages to server logs along with ps display
Date: 2021-12-08 05:17:57
Message-ID: CALj2ACU21YMk+f_60JaKaqQiU4A-xta5ko4r4PpcFrw1PvznhQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 8, 2021 at 10:05 AM Michael Paquier <michael(at)paquier(dot)xyz> 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 these messages at LOG level seem to be filling up
> > the server logs, having a good log consumption and rotation mechanism
> > (I'm sure every major postgres vendor would have one) would be
> > sufficient to allay that concern.
>
> + ereport(LOG,
> + (errmsg("recovering WAL segment \"%s\" from source \"%s\"",
> + xlogfname, srcname)));
> Isn't this approach an issue for translations? It seems to me that
> terms like "stream" or "archive" had better be translated properly,
> meaning that this needs a fully-constructed sentence.

Thanks for taking a look at the patch. How about the attached v4?

I added a CF entry - https://commitfest.postgresql.org/36/3443/

Regards,
Bharath Rupireddy.

Attachment Content-Type Size
v4-0001-add-log-messages-for-recovery.patch application/octet-stream 3.3 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2021-12-08 05:24:47 Re: row filtering for logical replication
Previous Message Amit Kapila 2021-12-08 05:15:48 Re: Skipping logical replication transactions on subscriber side