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
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 |