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