Re: Making pg_rewind faster
| От | John H |
|---|---|
| Тема | Re: Making pg_rewind faster |
| Дата | |
| Msg-id | CA+-JvFuUu05J=Ma__6gfQpV9Gya4O5kT04oBkPt7nMj5NXt09A@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Making pg_rewind faster (Srinath Reddy Sadipiralla <srinath2133@gmail.com>) |
| Ответы |
Re: Making pg_rewind faster
|
| Список | pgsql-hackers |
Hi,
On Wed, Oct 15, 2025 at 7:27 AM Srinath Reddy Sadipiralla
<srinath2133@gmail.com> wrote:
>
> TBH first it seemed to me a good coding practice for future proofing,
> then i checked if there's any place in postgres we are doing
> something similar ,then found 1 in src/include/access/gist.h
>
> typedef struct GISTDeletedPageContents
> {
> /* last xid which could see the page in a scan */
> FullTransactionId deleteXid;
> } GISTDeletedPageContents;
>
It makes more sense to me if we expect the struct or same set of arguments
to be reused in different places / want a stable API reference. I don't think
we want everything to be wrapped around a struct for functions just in case.
> ..
> thanks for updating, i have attached a diff patch on
> top of v9-0001 patch , where i tried to add more tests
> ...
Thank you for the diff! Your changes are a lot cleaner and I've included it in
the latest patch. One difference I've made is instead of additionally logging in
decide_wal_file_action
> + pg_log_debug("WAL segment \"%s\" is copied to target", fname);
I realized we are already logging the WAL segments that are copied over in
print_filemap so I've updated the test to check for that instead
> qr/pg_wal\/$corrupt_wal_seg \(COPY\)/
I also updated the error message for the last three checks.
Thanks,
--
John Hsu - Amazon Web Services
Вложения
В списке pgsql-hackers по дате отправления: