Re: Is this a problem in GenericXLogFinish()?

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: Is this a problem in GenericXLogFinish()?
Дата
Msg-id Zg99dfJ5t6k1wcB1@paquier.xyz
обсуждение исходный текст
Ответ на Re: Is this a problem in GenericXLogFinish()?  (Michael Paquier <michael@paquier.xyz>)
Ответы Re: Is this a problem in GenericXLogFinish()?  (Amit Kapila <amit.kapila16@gmail.com>)
RE: Is this a problem in GenericXLogFinish()?  ("Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>)
Re: Is this a problem in GenericXLogFinish()?  (Michael Paquier <michael@paquier.xyz>)
Список pgsql-hackers
On Wed, Feb 07, 2024 at 06:42:21PM +0900, Michael Paquier wrote:
> On Wed, Feb 07, 2024 at 02:08:42PM +0530, Amit Kapila wrote:
> > Thanks for the report and looking into it. Pushed!
>
> Thanks Amit for the commit and Kuroda-san for the patch!

I have been pinged about this thread and I should have looked a bit
closer, but wait a minute here.

There is still some divergence between the code path of
_hash_freeovflpage() and the replay in hash_xlog_squeeze_page() when
squeezing a page: we do not set the LSN of the write buffer if
(xlrec.ntups <= 0 && xlrec.is_prim_bucket_same_wrt &&
!xlrec.is_prev_bucket_same_wrt) when generating the squeeze record,
but at replay we call PageSetLSN() on the write buffer and mark it
dirty in this case.  Isn't that incorrect?  It seems to me that we
should be able to make the conditional depending on the state of the
xl_hash_squeeze_page record, no?
--
Michael

Вложения

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

Предыдущее
От: Ashutosh Bapat
Дата:
Сообщение: Re: Statistics Import and Export
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: LogwrtResult contended spinlock