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()?
|
Список | 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 по дате отправления: