Re: Can we change pg_rewind used without wal_log_hints and data_checksums

From: Movead <lchch1990(at)sina(dot)cn>
To: "Laurenz Albe" <laurenz(dot)albe(at)cybertec(dot)at>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Can we change pg_rewind used without wal_log_hints and data_checksums
Date: 2026-01-16 00:04:32
Message-ID: 2026011608042232790861@sina.cn
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2026-01-16 at 03:08 +0800, laurenz(dot)albe(at)cybertec(dot)at wrote:
>I had a brief look at the patch, and the gratuitous use of static variables didn't
>appeal to me. 
Sorry about that, and I can find a nice way if the design is good.

>Can you briefly describe the algorithm?
I think the algorithm is introduced in the patch mail, let me do a summary

During a forward WAL walk, the system collects the minimal commit transaction
ID. If it find when this transaction ID assigned, a safety rewind can be performed.

>You look at all commit records *after* the fork, right? 
It's all record after for fork, not only commited. I do not change the code logic.
Maybe commit record is enougn.

On the other hand, my patch collect all record *before* the fork, maybe
it will cause many meaningless copy and I can fix that.

>Then how can you identify how far back you have rewind? 
It's the point that we can known the stop point only by walk wal. So it maybe
take long time, and it's the reason I add a '-d, --deep-dig' option.

>How can you identify when a transaction started?
We find it by XLOG_RUNNING_XACTS wal record, this wal record have a *nextXid*
which mean a unassigned transaction id when produce the wal record.

 

----
Best Regards,
Movead Li

 

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chao Li 2026-01-16 00:51:52 Re: [PATCH] Fix incorrect parser comment
Previous Message Henson Choi 2026-01-15 23:44:42 Re: Row pattern recognition