Re: Add information to rm_redo_error_callback()

From: "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Masahiko Sawada <masahiko(dot)sawada(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Add information to rm_redo_error_callback()
Date: 2020-10-01 09:18:30
Message-ID: 4b827128-c0ee-bcf5-6ae6-65d5be266285@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 10/1/20 9:41 AM, Michael Paquier wrote:
> On Thu, Sep 24, 2020 at 03:03:46PM +0900, Michael Paquier wrote:
>> Hmm. I still think that knowing at least about a FPW could be an
>> interesting piece of information even here. Anyway, instead of
>> copying a logic that exists already in xlog_outrec(), why not moving
>> the block information print into a separate routine out of the
>> WAL_DEBUG section, and just reuse the same format for the context of
>> the redo error callback? That would also be more consistent with what
>> we do in pg_waldump where we don't show the fork name of a block when
>> it is on a MAIN_FORKNUM. And this would avoid a third copy of the
>> same logic. If we add the XID, previous LSN and the record length
>> on the stack of what is printed, we could just reuse the existing
>> routine, still that's perhaps too much information displayed.
> Seeing nothing, I took a swing at that, and finished with the
> attached that refactors the logic and prints the block information as
> wanted. Any objections to that?

Sorry for the late reply and thanks for looking at it!

Had a look at it and did a few tests: looks all good to me.

No objections at all, thanks!

Bertrand

> --
> Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Craig Ringer 2020-10-01 09:37:34 Re: Improving connection scalability: GetSnapshotData()
Previous Message Keisuke Kuroda 2020-10-01 09:12:54 Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables