Re: Release and unpin buffers after leaving CRIT section in GIN.
Вложения
В списке pgsql-hackers по дате отправления:
| От | Michael Paquier |
|---|---|
| Тема | Re: Release and unpin buffers after leaving CRIT section in GIN. |
| Дата | |
| Msg-id | aZa1fwYFD3-4BrDP@paquier.xyz обсуждение |
| Ответ на | Re: Release and unpin buffers after leaving CRIT section in GIN. (Kirill Reshke <reshkekirill@gmail.com>) |
| Список | pgsql-hackers |
On Tue, Feb 17, 2026 at 03:14:45PM +0500, Kirill Reshke wrote: > Looks like there are two more instances of this on HEAD: in gistbuild > and log_newpage_range. Is it? Planting an assertion in UnlockReleaseBuffer(), there are two extra places that can be spotted: - Most of the places reported by the regression tests seem to come from gistplacetopage(), with UnlockReleaseBuffer() called for a rootsplit. This case is actually OK to me, where the new buffers are all unlocked with the root page locked. I have to admit that I am not the best specialist ever on this one, so I may be missing something. - ginHeapTupleFastInsert(), with UnlockReleaseBuffer() called before GinGetPendingListCleanupSize(). This one is not in line, being registered as buffer in a XLOG_GIN_UPDATE_META_PAGE record. We could do better here. Saying that, the cases of createPostingTree()@gindatapage.c, the three in ginfast.c, the one in ginutil.c, the two in ginvacuum.c (one with only unpins), and xloginsert.c are no-brainers to me, so I have applied these. The two proposed cases in gininsert.c and gistbuild.c do nothing related to WAL-logging, though. -- Michael
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера