Re: Is this a problem in GenericXLogFinish()?

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: Is this a problem in GenericXLogFinish()?
Дата
Msg-id 57c59f08bbb92875251dc97dbc47600fa237712c.camel@j-davis.com
обсуждение исходный текст
Ответ на Re: Is this a problem in GenericXLogFinish()?  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: Is this a problem in GenericXLogFinish()?  (Jeff Davis <pgsql@j-davis.com>)
Список pgsql-hackers
On Wed, 2023-09-27 at 18:57 +0300, Heikki Linnakangas wrote:
> We could define a new REGBUF_NO_CHANGE flag to signal that the buffer
> is
> registered just for locking purposes, and not actually modified by
> the
> WAL record.

Out of curiosity I also added a trial assert (not intending to actually
add this):

  Assert(!(flags & REGBUF_NO_CHANGE) || !BufferIsExclusiveLocked());

I expected that to fail, but it didn't -- perhaps that buffer is only
locked during replay or something? I don't think we want that specific
Assert; I was just experimenting with some cross-checks we could do to
verify that REGBUF_NO_CHANGE is used properly.

Also, I ran into some problems with GIN that might require a bit more
refactoring in ginPlaceToPage(). Perhaps we could consider
REGBUF_NO_CHANGE a general bypass of the Assert(BufferIsDirty()), and
use it temporarily until we have a chance to analyze/refactor each of
the callers that need it.

Regards,
        Jeff Davis




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

Предыдущее
От: Alexander Korotkov
Дата:
Сообщение: Re: Index range search optimization
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges