Re: Can we change pg_rewind used without wal_log_hints and data_checksums
| От | Neil Chen |
|---|---|
| Тема | Re: Can we change pg_rewind used without wal_log_hints and data_checksums |
| Дата | |
| Msg-id | CAA3qoJmvMRPRrdjyKi5sEjb4uX6ONjvDLvRLhKRye8rogacAZw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Can we change pg_rewind used without wal_log_hints and data_checksums (Movead <lchch1990@sina.cn>) |
| Список | 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@sina.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.
В списке pgsql-hackers по дате отправления: