Shortening the Scope of Critical Section in Creation of New MultiXacts

Поиск
Список
Период
Сортировка
От Bagga, Rishu
Тема Shortening the Scope of Critical Section in Creation of New MultiXacts
Дата
Msg-id DEEB7863-5D47-4A5B-9974-DB70BC24E512@amazon.com
обсуждение исходный текст
Ответы Re: Shortening the Scope of Critical Section in Creation of New MultiXacts  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список 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)


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ian Lawrence Barwick
Дата:
Сообщение: Re: Proposal for internal Numeric to Uint64 conversion function.
Следующее
От: Tom Lane
Дата:
Сообщение: Re: wake up logical workers after ALTER SUBSCRIPTION