| 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 |
| Thread: | |
| 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 |
| 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 |