>On 1/3/23, 5:06 AM, "vignesh C" <vignesh21@gmail.com> wrote:
>>On Fri, 16 Dec 2022 at 04:47, Bagga, Rishu <bagrishu@amazon.com>
>>wrote:
>>Rebased and updated a new patch addressing the critical section issue in
>>RecordNewMultliXact.In GetNewMultiXactId, we now make our ReadBuffer
>>calls before starting the critical section, but while holding the
>>MultiXactGenLock, so we always fetch the correct buffers. We store
>>them in an array that is accessed later in RecordNewMultiXact.
>>This way we can keep the existing functionality of only holding the
>>MultiXactGenLock while reading in buffers, but can let go when we are
>>writing, to preserve the existing concurrency paradigm.
>>Let me know your thoughts on this approach.
> The patch does not apply on top of HEAD as in [1], please post a
>rebased patch:
>=== Applying patches on top of PostgreSQL commit ID
>92957ed98c5c565362ce665266132a7f08f6b0c0 ===
>=== applying patch ./slru_to_buffer_cache_with_page_headers_v3.patch
...
>patching file src/include/catalog/catversion.h
>Hunk #1 FAILED at 57.
>1 out of 1 hunk FAILED -- saving rejects to file
>src/include/catalog/catversion.h.rej
>[1] - http://cfbot.cputube.org/patch _41_3514.log
>Regards,
>Vignesh
Hi all,
Rebased the patch, and fixed a bug I introduced in the previous patch in
TrimCLOG.
We ran a quick set of pgbench tests and observed no regressions. Here
are the numbers:
3 trials, with scale 10,000, 350 clients, 350 threads, over 30 minutes:
Median TPS:
Control
Trial 1: 58331.0
Trial 2: 57191.0
Trial 3: 57101.3
Average of Medians: 57541.1
SLRUs to BufferCache + Page Headers:
Trial 1: 62605.0
Trial 2: 62891.2
Trial 3: 59906.3
Average of Medians: 61800.8
Machine Specs:
Driver
Instance: m5d.metal
Architecture x86_64
CPUs: 96
RAM: 384 GiB
OS: Amazon Linux 2
Server
Instance: r5dn.metal
Architecture x86_64
CPUs: 64
RAM: 500GiB
OS: Amazon Linux 2
Looking forward to your feedback on this.
Sincerely,
Rishu Bagga, Amazon Web Services (AWS)