Re: Add information to rm_redo_error_callback()

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: "Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com>
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 07:41:09
Message-ID: 20201001074109.GL8130@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?
--
Michael

Attachment Content-Type Size
redo-callback-block-v2.patch text/x-diff 1.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-10-01 07:47:18 Re: Protect syscache from bloating with negative cache entries
Previous Message Jaime Casanova 2020-10-01 07:09:03 Re: enable_incremental_sort changes query behavior