Re: Shortening the Scope of Critical Section in Creation of New MultiXacts - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Shortening the Scope of Critical Section in Creation of New MultiXacts
Date
Msg-id 20221214.144509.1790291251196831614.horikyota.ntt@gmail.com
Whole thread Raw
In response to Shortening the Scope of Critical Section in Creation of New MultiXacts  ("Bagga, Rishu" <bagrishu@amazon.com>)
List pgsql-hackers
Hello.

In short, the code as-is looks correct.

At Wed, 14 Dec 2022 00:14:34 +0000, "Bagga, Rishu" <bagrishu@amazon.com> wrote in 
>     * Critical section from here until caller has written the data into the
>     * just-reserved SLRU space; we don't want to error out with a partly

"the data" here means the whole this multi transaction, which includes
members. We shouldn't exit the critical section at least until the
very end of RecordNewMultiXact().

> This makes sense, as we need the multixact state and multixact offset 
> data to be consistent, but once we write data into the offsets, we can 
> end the critical section. Currently we wait until the members data is 
> also written before we end the critical section. 

Why do you think that the members are not a part of a
multitransaction?  A multitransaction is not complete without them.

Addition to the above, we cannot simply move the END_CRIT_SECTION() to
there since RecordNewMultiXact() has another caller that doesn't start
a critical section.

By the way, I didn't tested this for myself but..

> This passes regression tests

Maybe if you did the same with an assertion-build, you will get an
assertion-failure.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Use get_call_result_type() more widely
Next
From: Peter Eisentraut
Date:
Subject: Re: Non-decimal integer literals