Re: Making pg_rewind faster - Mailing list pgsql-hackers

From wenhui qiu
Subject Re: Making pg_rewind faster
Date
Msg-id CAGjGUAL0TvbwMjXcGQiTznss+b-g9ZAUq21PyApKpbb5y4hzGg@mail.gmail.com
Whole thread Raw
In response to Re: Making pg_rewind faster  (Japin Li <japinli@hotmail.com>)
List pgsql-hackers
Hi 
> Thanks, LGTM.
I think it's possible to register to https://commitfest.postgresql.org/54, https://commitfest.postgresql.org/53 will closed soon



Thanks

On Fri, Jul 4, 2025 at 10:50 AM Japin Li <japinli@hotmail.com> wrote:
On Thu, 03 Jul 2025 at 12:59, John H <johnhyvr@gmail.com> wrote:
> Hi,
>
> On Wed, Jul 2, 2025 at 6:40 PM Japin Li <japinli@hotmail.com> wrote:
>>
>> >
>>
>> Splitting the logs from $PGDATA is definitely better. The question is whether
>> it's worth implementing this directly in core or if a prominent note in the
>> documentation would suffice.
>>
>
> I can work on the documentation update as a separate patch if folks
> think this is worthwhile.
>
>> >> On Wed, Jul 2, 2025 at 10:21 AM Japin Li <japinli@hotmail.com> wrote:
>>
>> Exactly!  It's confusing that getFileType() returns file_content_type_t
>> instead of file_type_t.
>>
>
> Ah yes that is confusing, updated in patch.
>
>> For v5 patch:
>>
>> 1.
>> We could simply use the global WalSegSz variable within decide_file_action(),
>> eliminating the need to pass wal_segsz_bytes as an argument.
>>
>
> Good point.
>
>> 2.
>> For last_common_segno, we could implement it similarly to WalSegSz, avoiding a
>> signature change for decide_file_actions() and decide_file_action().  I'm not
>> insisting on this approach, however.
>>
>
> I made it a global as well, and had to include access/xlog_internal.h
> in pg_rewind.h but I don't feel strongly about it either way.
>

Thanks, LGTM.

--
Regards,
Japin Li

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Fix deprecation warning with libxml2 2.14 in contrib/xml2/
Next
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Conflict detection for update_deleted in logical replication