Hi, On 2016-03-24 01:10:55 +0100, Andres Freund wrote: > I'm afraid that this patch might be putting bandaid on some of the > absolutely worst cases, without actually addressing the core > problem. Simon's patch in [1] seems to come closer addressing that > (which I don't believe it's safe without going doing every status > manipulation atomically, as individual status bits are smaller than 4 > bytes). Now it's possibly to argue that the bandaid might slow the > bleeding to a survivable level, but I have to admit I'm doubtful. > > Here's the stats for a -s 500 run btw: > Performance counter stats for 'system wide': > 18,747 probe_postgres:TransactionIdSetTreeStatus > 68,884 probe_postgres:TransactionIdGetStatus > 9,718 probe_postgres:PGSemaphoreLock > (the PGSemaphoreLock is over 50% ProcArrayLock, followed by ~15% > SimpleLruReadPage_ReadOnly) > > > My suspicion is that a better approach for now would be to take Simon's > patch, but add a (per-page?) 'ClogModificationLock'; to avoid the need > of doing something fancier in TransactionIdSetStatusBit(). > > Andres > > [1]: > http://archives.postgresql.org/message-id/CANP8%2Bj%2BimQfHxkChFyfnXDyi6k-arAzRV%2BZG-V_OFxEtJjOL2Q%40mail.gmail.com
Simon, would you mind if I took your patch for a spin like roughly suggested above? Andres -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers