Committed.
--
nathan
On Fri, 11 Jul 2025 at 8:27 PM, Nathan Bossart
wrote:
> On Fri, Jul 11, 2025 at 08:43:05AM +0530, Dilip Kumar wrote:
> > Thanks now, looks good to me.
>
> Thanks for reviewing.
>
> > Additionally IMHO it would be good to add tests with FLUSH_UNLOGGED TRUE
> > and FLUSH_UNLOGGED FALSE as well, I h
On Fri, Jul 11, 2025 at 08:43:05AM +0530, Dilip Kumar wrote:
> Thanks now, looks good to me.
Thanks for reviewing.
> Additionally IMHO it would be good to add tests with FLUSH_UNLOGGED TRUE
> and FLUSH_UNLOGGED FALSE as well, I have added a simple 2 test for the
> same in attached file.
I'll add
On Thu, Jul 10, 2025 at 9:33 PM Nathan Bossart wrote:
>
> Thanks all for the feedback. Here is an updated patch set.
>
Thanks now, looks good to me. Additionally IMHO it would be good to
add tests with FLUSH_UNLOGGED TRUE and FLUSH_UNLOGGED FALSE as well, I
have added a simple 2 test for the sam
Thanks all for the feedback. Here is an updated patch set.
--
nathan
>From d862592acfb6470e34da9e993ff942c48cbf4e2f Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 9 Jul 2025 10:05:10 -0500
Subject: [PATCH v9 1/5] Rename CHECKPOINT_FLUSH_ALL to
CHECKPOINT_FLUSH_UNLOGGED.
The new name
On Thu, Jul 10, 2025 at 10:34 AM Dilip Kumar wrote:
>
> On Thu, Jul 10, 2025 at 9:55 AM Dilip Kumar wrote:
> >
> > On Thu, Jul 10, 2025 at 9:31 AM Fujii Masao
> > wrote:
> > >
> > >
> > >
> > > On 2025/07/10 4:26, Nathan Bossart wrote:
> > > > Here is what I have staged for commit, which I'm pl
On Thu, Jul 10, 2025 at 9:55 AM Dilip Kumar wrote:
>
> On Thu, Jul 10, 2025 at 9:31 AM Fujii Masao
> wrote:
> >
> >
> >
> > On 2025/07/10 4:26, Nathan Bossart wrote:
> > > Here is what I have staged for commit, which I'm planning to do on Friday.
> >
> > Thanks for updating the patches!
> >
> >
On Thu, Jul 10, 2025 at 9:31 AM Fujii Masao wrote:
>
>
>
> On 2025/07/10 4:26, Nathan Bossart wrote:
> > Here is what I have staged for commit, which I'm planning to do on Friday.
>
> Thanks for updating the patches!
>
> Regarding the 0005 patch:
>
> - COMPLETE_WITH("MODE");
On 2025/07/10 4:26, Nathan Bossart wrote:
Here is what I have staged for commit, which I'm planning to do on Friday.
Thanks for updating the patches!
Regarding the 0005 patch:
- COMPLETE_WITH("MODE");
+ COMPLETE_WITH("MODE, FLUSH_UNLOGGED");
Sho
Re: Nathan Bossart
> Here is what I have staged for commit, which I'm planning to do on Friday.
> diff --git a/doc/src/sgml/ref/pg_basebackup.sgml
> b/doc/src/sgml/ref/pg_basebackup.sgml
> index 9659f76042c..9be752fc12b 100644
> --- a/doc/src/sgml/ref/pg_basebackup.sgml
> +++ b/doc/src/sgml/ref/p
Here is what I have staged for commit, which I'm planning to do on Friday.
--
nathan
>From ffb16241a57bcbe35445754e606e47a073eedf0d Mon Sep 17 00:00:00 2001
From: Nathan Bossart
Date: Wed, 9 Jul 2025 10:05:10 -0500
Subject: [PATCH v8 1/5] Rename CHECKPOINT_FLUSH_ALL to
CHECKPOINT_FLUSH_UNLOGGED
Re: Nathan Bossart
> I broke this up into several small patches. Notable changes are as
> follows:
>
> * Adjusted to the tab completion code to work more like the VACUUM utility
> options.
>
> * Introduced a new ExecCheckpoint() function in checkpointer.c and moved
> the privilege check and
I broke this up into several small patches. Notable changes are as
follows:
* Adjusted to the tab completion code to work more like the VACUUM utility
options.
* Introduced a new ExecCheckpoint() function in checkpointer.c and moved
the privilege check and options parsing there.
* Removed t
Re: Nathan Bossart
> I think you've got it right. With CHECKPOINT_WAIT set, RequestCheckpoint()
> will wait for a new checkpoint to start, at which point we know that the
> new flags have been seen by the checkpointer. If an immediate checkpoint
> is pending, CheckpointWriteDelay() will skip slee
On Mon, Jun 16, 2025 at 04:36:59PM +0200, Christoph Berg wrote:
> I spent some time digging through the code, but I'm still not entirely
> sure what's happening. There are several parts to it:
>
> 1) the list of buffers to flush is determined at the beginning of the
> checkpoint, so running a 2nd
Re: Laurenz Albe
> How about the following for added clarity:
>
>Running an explicit CHECKPOINT is not required during
>normal operation; the system schedules checkpoints automatically
> (controlled
>by the settings in ).
>However, it can be useful to perform an explicit checkpoin
On Wed, 2025-06-11 at 17:53 +0200, Christoph Berg wrote:
> I haven't implemented a WAIT option yet since I didn't want to decide
> that without more votes in either direction.
I had a look at it, and I have suggestions for the documentation.
> --- a/doc/src/sgml/ref/checkpoint.sgml
> +++ b/doc/sr
On Wed, Jun 11, 2025 at 05:53:15PM +0200, Christoph Berg wrote:
> Ack, done in v4.
Thanks! The overall shape of these patches looks pretty good to me. I'll
aim to give them a deeper review in the near future.
--
nathan
Re: Nathan Bossart
> IMO we should try to make the terminology consistent everywhere. I'd
> suggest putting the renaming stuff in separate prerequisite patches for
> your new CHECKPOINT option.
Ack, done in v4.
I haven't implemented a WAIT option yet since I didn't want to decide
that without mo
On Wed, Jun 11, 2025 at 03:45:46PM +0200, Christoph Berg wrote:
> Do we want to change the checkpoint log message (and the new options)
> only, or include the CHECKPOINT_* flags? (I would guess there aren't
> many external users of these flags, but mmmv.)
IMO we should try to make the terminology
Re: Nathan Bossart
> That seems like a good idea to me. I'm tempted to say that "fast" more
> accurately describes what's happening than "immediate." "Immediate" sounds
> like it happens instantaneously, but it's actually just happening "fast,"
> i.e., as fast as possible.
Ack.
> > #define CHEC
On Fri, Jun 06, 2025 at 06:20:21PM +0200, Christoph Berg wrote:
> Re: Nathan Bossart
>> I don't understand why we need to add both FAST and IMMEDIATE.
>
> We have both:
>
> =# checkpoint ;
> 2025-06-06 18:09:25.743 CEST [872379] LOG: checkpoint starting: immediate
> force wait
>
> pg_basebacku
Re: Nathan Bossart
> I imagine the documentation will pretty clearly indicate that setting WAIT
> to "false" will cause CHECKPOINT to not wait for it to finish.
I can add it, it's easy enough...
> I don't understand why we need to add both FAST and IMMEDIATE.
We have both:
=# checkpoint ;
2025-
On Fri, Jun 06, 2025 at 04:26:56PM +0200, Christoph Berg wrote:
> Re: Fujii Masao
>> Some users might want to trigger a spread checkpoint but not wait for
>> it to finish, since it could take a long time? If that's a valid use case,
>> maybe we should add a WAIT option to let users choose whether t
Re: Fujii Masao
> utility.c:946:4: warning: label followed by a declaration is a C23 extension
> [-Wc23-extensions]
Thanks, my compiler didn't throw that. { } block added in v3.
> RequestCheckpoint(CHECKPOINT_WAIT |
> +
On 2025/06/06 19:03, Christoph Berg wrote:
Re: Andres Freund
I'd add a 'mode' that can be set to an arbitrary string, which then can be
validated in C code. That seems more future proof.
Changed in the attached v2, thanks.
When I applied the patch and compiled it, I got the following warn
Re: Andres Freund
> I'd add a 'mode' that can be set to an arbitrary string, which then can be
> validated in C code. That seems more future proof.
Changed in the attached v2, thanks.
Christoph
>From c8975cbd1dbe5e5cae18414ea27bc3f2c0e8 Mon Sep 17 00:00:00 2001
From: Christoph Berg
Date: Fri
Re: Andres Freund
> Hi,
>
> On 2025-05-30 18:17:45 +0200, Christoph Berg wrote:
> > A customer reported to use CHECKPOINT before shutdowns to make the
> > shutdowns themselves faster and asked if it was possible to make
> > CHECKPOINT optionally also write out unlogged table data for that
> > purp
Re: Nathan Bossart
> This patch also adds an IMMEDIATE option, which I proposed some time ago
> [0]. I ended up withdrawing it due to general skepticism about its
Thanks for the pointer, I did not go that far back when looking for
older threads.
When writing the patch, I was also thinking about
On 2025-05-30 19:23:04 +0200, Christoph Berg wrote:
> Re: Nathan Bossart
> > This patch also adds an IMMEDIATE option, which I proposed some time ago
> > [0]. I ended up withdrawing it due to general skepticism about its
>
> Thanks for the pointer, I did not go that far back when looking for
> ol
On Fri, May 30, 2025 at 12:39:02PM -0400, Andres Freund wrote:
> On 2025-05-30 18:17:45 +0200, Christoph Berg wrote:
>> A customer reported to use CHECKPOINT before shutdowns to make the
>> shutdowns themselves faster and asked if it was possible to make
>> CHECKPOINT optionally also write out unlo
Hi,
On May 30, 2025 12:55:28 PM EDT, Christoph Berg wrote:
>Re: Andres Freund
>> Hi,
>>
>> On 2025-05-30 18:17:45 +0200, Christoph Berg wrote:
>> > A customer reported to use CHECKPOINT before shutdowns to make the
>> > shutdowns themselves faster and asked if it was possible to make
>> > CHECK
Hi,
On 2025-05-30 18:17:45 +0200, Christoph Berg wrote:
> A customer reported to use CHECKPOINT before shutdowns to make the
> shutdowns themselves faster and asked if it was possible to make
> CHECKPOINT optionally also write out unlogged table data for that
> purpose. I think the idea makes sens
A customer reported to use CHECKPOINT before shutdowns to make the
shutdowns themselves faster and asked if it was possible to make
CHECKPOINT optionally also write out unlogged table data for that
purpose. I think the idea makes sense, so there's the patch.
Christoph
>From 1d7d7b7fab78312f5423dff
34 matches
Mail list logo
