Re: BUG #19006: Assert(BufferIsPinned) in BufferGetBlockNumber() is triggered for forwarded buffer

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: BUG #19006: Assert(BufferIsPinned) in BufferGetBlockNumber() is triggered for forwarded buffer
Дата
Msg-id CA+hUKG+cK955=G2gWPcK-yeAx1jz5Ln9_q=x9hMVjU=0zH8=dA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #19006: Assert(BufferIsPinned) in BufferGetBlockNumber() is triggered for forwarded buffer  (Thomas Munro <thomas.munro@gmail.com>)
Ответы Re: BUG #19006: Assert(BufferIsPinned) in BufferGetBlockNumber() is triggered for forwarded buffer
Список pgsql-bugs
On Sat, Aug 9, 2025 at 3:06 AM Thomas Munro <thomas.munro@gmail.com> wrote:
> Well, one benefit of trying to describe a complex system from the top
> is that higher level stupidity can sometimes become clear...  I
> realised that the queue wouldn't even need to be initialised or
> cleared if StartReadBuffers() had an explicit in/out npinned argument
> to transmit the count between calls along with the buffers, or
> examined after each call.  This is a draft alternative fix that I am
> studying that removes quite a lot of lines and fragility, though time
> is not on my side so I might push the one-liner fix ahead of the
> upcoming freeze and then see what to do about this.

One-liner fix pushed.

Here is a new version of the slightly more ambitious fix, for
discussion.  I need to figure out if there is any measurable
performance impact, but from an interface sanity and fragility POV it
seems infinitely better like this.  I recall being paranoid about
function call width, but it still fits in 6 registers.  I think
perhaps the InvalidBuffer-based API might have seemed a shade more
reasonable before I reworked the pin limiting logic, but once I had to
start scanning for forwarded buffers after every StartReadBuffers()
call, I really should have reconsidered that interface.  In other
words, maybe a bit of myopic path dependency here...

Вложения

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