On Tue, Nov 8, 2016 at 5:18 PM, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > Hello, > >> on something else than LW_EXCLUSIVE compared to now. To keep things >> more simple I' would still favor using WALInsertLocks for this patch, >> that looks more consistent, and also because there is no noticeable >> difference. > > Ok, the patch looks fine. So there's nothing for me but to accept > the current shape since the discussion about performance seems > not to be settled with out performance measurement with machines > with many cores. >
I think it is good to check the performance impact of this patch on many core m/c. Is it possible for you to once check with Alexander Korotkov to see if he can provide you access to his powerful m/c which has 70 cores (if I remember correctly)? @@ -1035,6 +1038,7 @@ LogAccessExclusiveLocks(int nlocks, xl_standby_lock *locks) XLogBeginInsert(); XLogRegisterData((char *) &xlrec, offsetof(xl_standby_locks, locks)); XLogRegisterData((char *) locks, nlocks * sizeof(xl_standby_lock)); + XLogSetFlags(XLOG_NO_PROGRESS); Is it right to set XLOG_NO_PROGRESS flag in LogAccessExclusiveLocks? This function is called not only in LogStandbySnapshot(), but during DDL operations as well where lockmode >= AccessExclusiveLock. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
