| From: | Neil Chen <carpenter(dot)nail(dot)cz(at)gmail(dot)com> |
|---|---|
| To: | Movead <lchch1990(at)sina(dot)cn> |
| Cc: | 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 14:38:35 |
| Message-ID: | CAA3qoJmvMRPRrdjyKi5sEjb4uX6ONjvDLvRLhKRye8rogacAZw@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Movead,
It's an interesting idea.
While it’s impossible to predict exactly how much WAL we’ll need to
backtrack through --
I assume it mainly depends on the duration of long-running transactions --
this approach
seems to offer an opportunity using pg_rewind without enabling
wal_log_hints.
On Fri, Jan 16, 2026 at 9:28 PM Movead <lchch1990(at)sina(dot)cn> wrote:
>
> In fact the min_commited_xid and max_commited_xid is the edge transaction
> commited after
> diverge record, so it's enough.
>
>
Given the potential large gap between transaction IDs (especially when
long-running transactions are involved),
maintaining a list/bitmap struct would be worthwhile.
A minor suggestion, for an operation that may fail, I suggest retrieving
the first XLOG_RUNNING_XACTS record to obtain its base_xid
before doing the deep-dig process. If the task cannot be completed (i.e.,
the base_xid <= min_commited_xid condition isn’t met),
we can throw an error immediately instead of waiting for all WAL records to
be parsed.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Geier | 2026-01-16 14:42:38 | Re: Hackorum - a new mailing list frontend |
| Previous Message | Movead | 2026-01-16 14:36:56 | Re: Can we change pg_rewind used without wal_log_hints and data_checksums |