Re: Is this a problem in GenericXLogFinish()? - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Is this a problem in GenericXLogFinish()?
Date
Msg-id 57c59f08bbb92875251dc97dbc47600fa237712c.camel@j-davis.com
Whole thread Raw
In response to Re: Is this a problem in GenericXLogFinish()?  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: Is this a problem in GenericXLogFinish()?
List 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 by date:

Previous
From: Alexander Korotkov
Date:
Subject: Re: Index range search optimization
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Extend ALTER OPERATOR to support adding commutator, negator, hashes, and merges