Re: Add information to rm_redo_error_callback()

Поиск
Список
Период
Сортировка
От Drouvot, Bertrand
Тема Re: Add information to rm_redo_error_callback()
Дата
Msg-id 4b827128-c0ee-bcf5-6ae6-65d5be266285@amazon.com
обсуждение исходный текст
Ответ на Re: Add information to rm_redo_error_callback()  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Add information to rm_redo_error_callback()  (Michael Paquier <michael@paquier.xyz>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Keisuke Kuroda
Дата:
Сообщение: Re: Logical replication CPU-bound with TRUNCATE/DROP/CREATE many tables
Следующее
От: Craig Ringer
Дата:
Сообщение: Re: Improving connection scalability: GetSnapshotData()