On 9/28/16 10:32 PM, Michael Paquier wrote:
On Thu, Sep 29, 2016 at 7:45 AM, David Steele <da...@pgmasters.net> wrote:
In general I agree with the other comments that this could end up being
a problem. On the other hand, since the additional locks are only taken
at checkpoint or archive_timeout it may not be that big a deal.
Yes, I did some tests on my laptop a couple of months back, that has 4
cores. After reducing NUM_XLOGINSERT_LOCKS from 8 to 4 to increase
contention and performing a bunch of INSERT using 4 clients on 4
different relations I could not catch a difference.. Autovacuum was
disabled to eliminate any noise. I tried checkpoint_segments at 30s to
see its effects, as well as larger values to see the impact with the
standby snapshot taken by the bgwriter. Other thoughts are welcome.
I don't have any better ideas than that.
+++ b/src/backend/postmaster/checkpointer.c
+ /* OK, it's time to switch */
+ elog(LOG, "Request XLog Switch");
LOG level seems a bit much here, perhaps DEBUG1?
That's from Horiguchi-san's patch, and those would be definitely
better as DEBUG1 by looking at it. Now and in order to keep things
simple I think that we had better discard this patch for now. I was
planning to come back to this thing anyway once we are done with the
first problem.
I still see this:
+++ b/src/backend/postmaster/checkpointer.c
/* OK, it's time to switch */
+ elog(LOG, "Request XLog Switch");
Well for now attached are two patches, that could just be squashed into one.
Yes, I think that makes sense.
More importantly, there is a regression. With your new patch the xlogs
are switching on archive_timeout again even with no changes. The v12
worked fine.
The differences are all in 0002-hs-checkpoints-v12-2.patch and as far as
I can see the patch does not work correctly without these changes. Am I
missing something?
--
-David
da...@pgmasters.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
