From: | wenhui qiu <qiuwenhuifx(at)gmail(dot)com> |
---|---|
To: | Japin Li <japinli(at)hotmail(dot)com> |
Cc: | John H <johnhyvr(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Andres Freund <andres(at)anarazel(dot)de>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Justin Kwan <justinpkwan(at)outlook(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, vignesh <vignesh(at)cloudflare(dot)com>, vignesh ravichandran <admin(at)viggy28(dot)dev>, "hlinnaka(at)iki(dot)fi" <hlinnaka(at)iki(dot)fi>, "jkwan(at)cloudflare(dot)com" <jkwan(at)cloudflare(dot)com> |
Subject: | Re: Making pg_rewind faster |
Date: | 2025-07-02 03:16:25 |
Message-ID: | CAGjGUAJHR8cb-s6TOtRicxsNsqJEL_doaoUAsFfgTjv0UYywKw@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
HI
> 2.
> Perhaps decide_wal_file_action() could be defined in filemap.c.
> While this is unrelated to WAL logging, it could also contribute to
faster
> pg_rewind operations. Should we consider ignoring log files under PGDATA
> (e.g., those in the default log/ directory)?
Agree ,Usually the log file directory also takes up a lot of space, and the
number of log files is quite large
On Wed, Jul 2, 2025 at 10:21 AM Japin Li <japinli(at)hotmail(dot)com> wrote:
> On Tue, 01 Jul 2025 at 11:13, John H <johnhyvr(at)gmail(dot)com> wrote:
> > Hi,
> >
> > I've attached an updated version of the patch against master with the
> changes
> > suggested.
> >
> > On Tue, Nov 29, 2022 at 10:03 PM Michael Paquier <michael(at)paquier(dot)xyz>
> wrote:
> >>
> >> On Thu, Oct 06, 2022 at 04:08:45PM +0900, Michael Paquier wrote:
> >>>
> >>> There may be something I am missing here, but there is no need to care
> >>> about segments with a TLI older than lastcommontliIndex, no?
> >
> > Hard to say. pg_rewind is intended to make the same "copy" of the
> cluster which
> > implies pg_wal/ should look the same. There might be use cases around
> logical
> > replication where you would want these WAL files to still exist even
> > across promotions?
> >
> >>> decide_wal_file_action() assumes that the WAL segment exists on the
> >>> target and the source. This looks bug-prone to me without at least an
> >>> assertion.
> >
> > From previous refactors there is now an Assertion in filemap.c
> > decide_file_action that handles this.
> >
> >> Assert(entry->target_exists && entry->source_exists);
> >
> > decide_wal_file_action is called after the assertion.
> >
>
> Hi, John
>
> Thanks for updating the patch.
>
> 1.
> +/* Determine the type of file content (relation, WAL, or other) */
> +static file_content_type_t
> +getFileType(const char *path)
>
> Considering the existence of file_type_t, would getFileContentType() be a
> suitable function for handling file content types?
>
> 2.
> Perhaps decide_wal_file_action() could be defined in filemap.c.
>
>
> While this is unrelated to WAL logging, it could also contribute to faster
> pg_rewind operations. Should we consider ignoring log files under PGDATA
> (e.g., those in the default log/ directory)?
>
> --
> Regards,
> Japin Li
>
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jianghua Yang | 2025-07-02 03:30:53 | Re: [PATCH] initdb: Treat empty -U argument as unset username |
Previous Message | David G. Johnston | 2025-07-02 03:11:58 | Re: [PATCH] initdb: Treat empty -U argument as unset username |