Hi,
Thanks for the review.
On Sun, Jul 6, 2025 at 7:12 PM wenhui qiu wrote:
>
> Hi
> > Thanks, LGTM.
> I think it's possible to register to https://commitfest.postgresql.org/54,
> https://commitfest.postgresql.org/53 will closed soon
>
I've created the commitfest entry here:
https://commitfest
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 wrote:
> On Thu, 03 Jul 2025 at 12:59, John H wrote:
> > Hi,
> >
> > On Wed, Jul 2, 2025 at 6:40
On Thu, 03 Jul 2025 at 12:59, John H wrote:
> Hi,
>
> On Wed, Jul 2, 2025 at 6:40 PM Japin Li 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 su
Hi,
On Wed, Jul 2, 2025 at 6:40 PM Japin Li 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 se
On Wed, 02 Jul 2025 at 11:21, John H wrote:
> Hi,
>
> Thanks for the quick review.
>
> On Tue, Jul 1, 2025 at 8:16 PM wenhui qiu wrote:
>> > Perhaps decide_wal_file_action() could be defined in filemap.c.
>>
>
> That's a good point. I updated the patch to reflect that.
>
Thanks for updating the
Hi,
Thanks for the quick review.
On Tue, Jul 1, 2025 at 8:16 PM wenhui qiu wrote:
> > Perhaps decide_wal_file_action() could be defined in filemap.c.
>
That's a good point. I updated the patch to reflect that.
> > While this is unrelated to WAL logging, it could also contribute to faster
> >
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 lo
On Tue, 01 Jul 2025 at 11:13, John H 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 wrote:
>>
>> On Thu, Oct 06, 2022 at 04:08:45PM +0900, Michael Paquier wrote:
>>>
>>> There may be
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 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
On Thu, Oct 06, 2022 at 04:08:45PM +0900, Michael Paquier wrote:
> file_entry_t has an entry to track if a file is a relation file. I
> think that it would be much cleaner to track if we are handling a WAL
> segment when inserting an entry in insert_filehash_entry(), so
> isrelfile could be replac
On Sun, Oct 02, 2022 at 10:44:25AM -0700, Andres Freund wrote:
> It doesn't seem quite right to read pg_rewind's logs by reading
> regress_log_001_basic. Too easy to confuse different runs of pg_rewind
> etc. I'd suggest trying to redirect the log to a different file.
Hardcoding log file names in
Hi,
On 2022-09-13 20:50:20 +0300, Alexander Korotkov wrote:
> On Fri, Jul 29, 2022 at 1:05 PM Justin Kwan wrote:
> > Not sure if this email went through previously but thank you for your
> > feedback, I've incorporated your suggestions by scanning the logs produced
> > from pg_rewind when asser
Hi, Justin!
On Fri, Jul 29, 2022 at 1:05 PM Justin Kwan wrote:
> Not sure if this email went through previously but thank you for your
> feedback, I've incorporated your suggestions by scanning the logs produced
> from pg_rewind when asserting that certain WAL segment files were skipped
> from
an ; hlinn...@iki.fi
Subject: Re: Making pg_rewind faster
Hi Tom,
Thank you for taking a look at this and that sounds good. I will send over a
patch compatible with Postgres v16.
Justin
From: Tom Lane
Sent: July 17, 2022 2:40 PM
To: Justin Kwan
Cc: pgs
Re: Making pg_rewind faster
On Mon, Jul 18, 2022 at 05:14:00PM +, Justin Kwan wrote:
> Thank you for taking a look at this and that sounds good. I will
> send over a patch compatible with Postgres v16.
+$node_2->psql(
+ 'postgres',
+ "SELECT extract(epoch fro
On Mon, Jul 18, 2022 at 05:14:00PM +, Justin Kwan wrote:
> Thank you for taking a look at this and that sounds good. I will
> send over a patch compatible with Postgres v16.
+$node_2->psql(
+ 'postgres',
+ "SELECT extract(epoch from modification) FROM
pg_stat_file('pg_wal/0001
ravichandran ; hlinn...@iki.fi
Subject: Re: Making pg_rewind faster
Justin Kwan writes:
> I've also attached the pg_rewind optimization patch file for Postgres version
> 14.4. The previous patch file targets version Postgres version 15 Beta 1/2.
It's very unlikely that we would consider
Justin Kwan writes:
> I've also attached the pg_rewind optimization patch file for Postgres version
> 14.4. The previous patch file targets version Postgres version 15 Beta 1/2.
It's very unlikely that we would consider committing such changes into
released branches. In fact, it's too late even
ustin
From: Justin Kwan
Sent: July 15, 2022 6:13 PM
To: vignesh ravichandran
Cc: pgsql-hackers ; vignesh
; justinpk...@outlook.com
Subject: Re: Making pg_rewind faster
Looping in my other email.
On Thu, Jun 30, 2022 at 6:22 AM vignesh ravichandran
mailto:ad...@vi
n
Cc: pgsql-hackers ; vignesh
; justinpk...@outlook.com
Subject: Re: Making pg_rewind faster
Looping in my other email.
On Thu, Jun 30, 2022 at 6:22 AM vignesh ravichandran
mailto:ad...@viggy28.dev>> wrote:
Hi Hackers,
I have been using pg_rewind in production for 2 years. One of the th
Hi Hackers,
I have been using pg_rewind in production for 2 years. One of the things that I
noticed in pg_rewind is if it doesn't know what to do with a file "it copies".
I understand it's the more safer option. After all, the alternative,
pg_basebackup copies all the files from source to tar
21 matches
Mail list logo
