LogwrtResult contended spinlock

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Pg Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Cc: Jaime Casanova <jaime(dot)casanova(at)2ndQuadrant(dot)com>
Subject: LogwrtResult contended spinlock
Date: 2020-08-31 18:21:56
Message-ID: 20200831182156.GA3983@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Jaime Casanova recently reported a situation where pglogical replicating
from 64 POS sites to a single central (64-core) node, each with two
replication sets, causes XLog's info_lck to become highly contended
because of frequently reading LogwrtResult. We tested the simple fix of
adding a new LWLock that protects LogwrtResult and LogwrtRqst; that
seems to solve the problem easily enough.

At first I wanted to make the new LWLock cover only LogwrtResult proper,
and leave LogwrtRqst alone. However on doing it, it seemed that that
might change the locking protocol in a nontrivial way. So I decided to
make it cover both and call it a day. We did verify that the patch
solves the reported problem, at any rate.

Álvaro Herrera PostgreSQL Expert, https://www.2ndQuadrant.com/

Attachment Content-Type Size
0001-use-an-LWLock-rather-than-spinlock-for-Logwrt-Result.patch text/x-diff 9.0 KB


Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-08-31 18:29:38 Re: LogwrtResult contended spinlock
Previous Message Victor Spirin 2020-08-31 18:20:28 Sometimes the output to the stdout in Windows disappears