From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | bagrishu(at)amazon(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org, manjuzna(at)amazon(dot)com, sdn(at)amazon(dot)com, paquier(at)amazon(dot)co(dot)jp, thomas(dot)munro(at)gmail(dot)com, hlinnaka(at)iki(dot)fi |
Subject: | Re: Shortening the Scope of Critical Section in Creation of New MultiXacts |
Date: | 2022-12-14 05:45:09 |
Message-ID: | 20221214.144509.1790291251196831614.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello.
In short, the code as-is looks correct.
At Wed, 14 Dec 2022 00:14:34 +0000, "Bagga, Rishu" <bagrishu(at)amazon(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Eisentraut | 2022-12-14 05:47:28 | Re: Non-decimal integer literals |
Previous Message | Bharath Rupireddy | 2022-12-14 05:44:59 | Re: Use get_call_result_type() more widely |