(Squashing replies) On Fri, Sep 30, 2016 at 6:13 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Fri, Sep 30, 2016 at 2:51 PM, Michael Paquier > <michael.paqu...@gmail.com> wrote: >> On Fri, Sep 30, 2016 at 2:05 PM, Kyotaro HORIGUCHI >> <horiguchi.kyot...@lab.ntt.co.jp> wrote: >>> At Fri, 30 Sep 2016 14:00:15 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI >>> <horiguchi.kyot...@lab.ntt.co.jp> wrote in >>> <20160930.140015.150178454.horiguchi.kyot...@lab.ntt.co.jp> >>>> I don't see no problem in setting progressAt in XLogInsertRecord. >>>> But I doubt GetProgressRecPtr is harmful, especially when >>> >>> But I suspect that GetProgressRecPtr could be harmful. >> >> Well, you can maximize its effects by doing NUM_XLOGINSERT_LOCKS == >> nproc and reducing checkpoint_timeout. That's what I did but.. > > Note: I am moving this patch to next CF.
And I am back on it more seriously... And I am taking back what I said upthread. I looked at the v12 that Horiguchi-san has written, and that seems correct to me. So I have squashed everything into a single patch, including the log entry that gets logged with log_checkpoints. Testing with archive_timeout to 10s, checkpoint_timeout to 30s, sometimes triggering manual activity with CREATE TABLE/whatever and manual pg_switch_xlog(), I am able to see that checkpoints can be correctly skipped or generated. There was as well a compilation error with ereport(). Not sure how I missed that... Likely too many patches handled these days. I have also updated the description of archive_timeout that increasing checkpoint_timeout would reduce unnecessary checkpoints on a idle system. With this patch, on an idle system checkpoints are just skipped as they should. How does that look? -- Michael
hs-checkpoints-v14.patch
Description: application/download
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
