Re: A few new options for CHECKPOINT

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Bernd Helmle <mailings(at)oopsware(dot)de>, "tsunakawa(dot)takay(at)fujitsu(dot)com" <tsunakawa(dot)takay(at)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: A few new options for CHECKPOINT
Date: 2020-12-14 21:53:45
Message-ID: 6F4478E0-E9FD-4FBC-8338-139E0B9DCFFE@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 12/5/20, 9:11 AM, "Stephen Frost" <sfrost(at)snowman(dot)net> wrote:
> * Bossart, Nathan (bossartn(at)amazon(dot)com) wrote:
>> On 12/5/20, 6:41 AM, "Stephen Frost" <sfrost(at)snowman(dot)net> wrote:
>> > Assuming we actually want to do this, which I still generally don't
>> > agree with since it isn't really clear if it'll actually end up doing
>> > something, or not, wouldn't it make more sense to have a command that
>> > just sits and waits for the currently running (or next) checkpoint to
>> > complete..? For the use-case that was explained, at least, we don't
>> > actually need to cause another checkpoint to happen, we just want to
>> > know when a checkpoint has completed, right?
>>
>> If it's enough to just wait for the current checkpoint to complete or
>> to wait for the next one to complete, I suppose you could just poll
>> pg_control_checkpoint(). I think the only downside is that you could
>> end up sitting idle for a while, especially if checkpoint_timeout is
>> high and checkpoint_completion_target is low. But, as you point out,
>> that may not be a typically recommended way to configure the system.
>
> Maybe I missed something, but aren't you going to be waiting a while
> with this patch given that it's asking for a spread checkpoint too..?
>
> I agree that you could just monitor for the next checkpoint using
> pg_control_checkpoint(), which is why I'm wondering again what the
> point is behind this patch... I'm trying to understand why we'd be
> encouraging people to increase the number of checkpoints that are
> happening when they're still going to be waiting around for that spread
> (in other words, non-immediate) checkpoint to happen (just as if they'd
> just waited until the next regular checkpoint), and they're still going
> to have a fair bit of WAL to replay because it'll be however much WAL
> has been written since we started the spread/non-immediate checkpoint.

I plan to mark this patch as withdrawn after the next commitfest
unless anyone objects.

Nathan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-12-14 22:01:37 Re: HASH_BLOBS hazards (was Re: PATCH: logical_work_mem and logical streaming of large in-progress transactions)
Previous Message Tom Lane 2020-12-14 21:40:02 Re: Optimizing the documentation