Re: PANIC: wrong buffer passed to visibilitymap_clear
От | Tom Lane |
---|---|
Тема | Re: PANIC: wrong buffer passed to visibilitymap_clear |
Дата | |
Msg-id | 3139938.1618277599@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PANIC: wrong buffer passed to visibilitymap_clear (Peter Geoghegan <pg@bowt.ie>) |
Ответы |
Re: PANIC: wrong buffer passed to visibilitymap_clear
|
Список | pgsql-hackers |
Peter Geoghegan <pg@bowt.ie> writes: > On Mon, Apr 12, 2021 at 9:19 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Hence, I propose the attached. It passes check-world, but that proves >> absolutely nothing of course :-(. I wonder if there is any way to >> exercise these code paths deterministically. > This approach seems reasonable to me. At least you've managed to > structure the visibility map page pin check as concomitant with the > existing space recheck. Thanks for looking it over. Do you have an opinion on whether or not to back-patch? As far as we know, these bugs aren't exposed in the back branches for lack of code that would set the all-visible flag without superexclusive lock. But I'd still say that heap_update is failing to honor its API contract in these edge cases, and that seems like something that could bite us after future back-patches. Or there might be third-party code that can set all-visible flags. So I'm kind of tempted to back-patch, but it's a judgment call. regards, tom lane
В списке pgsql-hackers по дате отправления: