Re: Is this a problem in GenericXLogFinish()?
От | Jeff Davis |
---|---|
Тема | Re: Is this a problem in GenericXLogFinish()? |
Дата | |
Msg-id | 146426fc662f88604c700a72a3833b1919922f9e.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 00:14 +0300, Heikki Linnakangas wrote: > Looks correct. You now loop through all the block IDs three times, > however. I wonder if that is measurably slower, but even if it's not, > was there a reason you wanted to move the XLogRegisterBuffer() calls > to > a separate loop? I did so to correspond more closely to what's outlined in the README and in other places in the code, where marking the buffers dirty happens before XLogBeginInsert(). It didn't occur to me that one extra loop would matter, but I can combine them again. It would be a bit more concise to do the XLogBeginInsert() first (like before) and then register the buffers in the same loop that does the writes and marks the buffers dirty. Updated patch attached. > > Hmm, I'm sure there are exceptions but log_newpage_range() actually > seems to be doing the right thing; it calls MarkBufferDirty() before > XLogInsert(). It only calls it after XLogRegisterBuffer() though, and > I > concur that XLogRegisterBuffer() would be the logical place for the > assertion. We could tighten this up, require that you call > MarkBufferDirty() before XLogRegisterBuffer(), and fix all the > callers. That site is pretty trivial to fix, but there are also a couple places in hash.c and hashovfl.c that are registering a clean page and it's not clear to me exactly what's going on. Regards, Jeff Davis
Вложения
В списке pgsql-hackers по дате отправления: