Re: checkpoints taking much longer than expected

From: Andres Freund <andres(at)anarazel(dot)de>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Tiemen Ruiten <t(dot)ruiten(at)tech-lab(dot)io>, Stephen Frost <sfrost(at)snowman(dot)net>, Postgres General <pgsql-general(at)postgresql(dot)org>
Subject: Re: checkpoints taking much longer than expected
Date: 2019-06-17 17:43:34
Message-ID: 20190617174334.ajdu667gcgjxt7f3@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 2019-06-16 12:25:58 -0400, Jeff Janes wrote:
> Right, but true only because they were "checkpoint starting: immediate".
> Otherwise the reported write time includes intentional sleeps added to
> honor the checkpoint_completion_target. A bit confusing to report it that
> way, I think.

+1

It's even worse than that, actually. We also don't sleep if the *next*
requested checkpoint is an immediate one:

* Perform the usual duties and take a nap, unless we're behind schedule,
* in which case we just try to catch up as quickly as possible.
*/
if (!(flags & CHECKPOINT_IMMEDIATE) &&
!shutdown_requested &&
!ImmediateCheckpointRequested() &&
IsCheckpointOnSchedule(progress))

/*
* Returns true if an immediate checkpoint request is pending. (Note that
* this does not check the *current* checkpoint's IMMEDIATE flag, but whether
* there is one pending behind it.)
*/
static bool
ImmediateCheckpointRequested(void)

We ought to do better.

- Andres

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Adrian Klaver 2019-06-17 18:56:12 Re: Copy Bulk Ignore Duplicated
Previous Message Leandro Guimarães 2019-06-17 17:04:11 Re: Copy Bulk Ignore Duplicated