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

From Bagga, Rishu
Subject Shortening the Scope of Critical Section in Creation of New MultiXacts
Date
Msg-id DEEB7863-5D47-4A5B-9974-DB70BC24E512@amazon.com
Whole thread Raw
Responses Re: Shortening the Scope of Critical Section in Creation of New MultiXacts  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
Hi all, 

I have been going through the multixact code over the last few 
weeks, and noticed a potential discrepancy between the need for critical 
sections in the creation of new multixacts and the current code.

As per the comment in GetNewMultiXact:


    /*
     * 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
     * written MultiXact structure.  (In particular, failing to write our
     * start offset after advancing nextMXact would effectively corrupt the
     * previous MultiXact.)
     */
    START_CRIT_SECTION()


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. 


I’ve attached a patch that moves the end of the critical section into 
RecordNewMultiXact, right after we finish writing data into the offsets 
cache.

This passes regression tests, as well as some custom testing around 
injecting random failures while writing multixact members, and 
restarting.

I would appreciate any feedback on this.


Sincerely, 

Rishu Bagga, Amazon Web Services (AWS)


Attachment

pgsql-hackers by date:

Previous
From: Ian Lawrence Barwick
Date:
Subject: Re: Proposal for internal Numeric to Uint64 conversion function.
Next
From: Tom Lane
Date:
Subject: Re: wake up logical workers after ALTER SUBSCRIPTION