Re: Issue in GIN fast-insert: XLogBeginInsert + Read/LockBuffer ordering
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: Issue in GIN fast-insert: XLogBeginInsert + Read/LockBuffer ordering |
| Дата | |
| Msg-id | Y0Yh5Xarpb894cRH@paquier.xyz обсуждение исходный текст |
| Ответ на | Re: Issue in GIN fast-insert: XLogBeginInsert + Read/LockBuffer ordering (Zhang Mingli <zmlpostgres@gmail.com>) |
| Ответы |
Re: Issue in GIN fast-insert: XLogBeginInsert + Read/LockBuffer ordering
|
| Список | pgsql-hackers |
On Fri, Sep 30, 2022 at 06:22:02PM +0800, Zhang Mingli wrote: > In the same function, there is disorder of XLogBeginInsert and START_CRIT_SECTION. > > ``` > collectordata = ptr = (char *) palloc(collector->sumsize); > > data.ntuples = collector->ntuples; > > if (needWal) > XLogBeginInsert(); > > START_CRIT_SECTION(); > ``` > > Shall we adjust that too? Nice catches, both of you. Let's adjust everything spotted in one shot. Matthias' patch makes the ordering right, but the initialization path a bit harder to follow when using a separate list. The code is short so it does not strike me as a big deal, and it comes from the fact that we need to lock an existing buffer when merging two lists. For the branch where we insert into a tail page, the pages are already locked but it looks to be enough to move XLogBeginInsert() before the first XLogRegisterBuffer() call. Would any of you like to write a patch? -- Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера