Re: Is this a problem in GenericXLogFinish()?

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Is this a problem in GenericXLogFinish()?
Date: 2023-09-26 23:13:32
Message-ID: 146426fc662f88604c700a72a3833b1919922f9e.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Attachment Content-Type Size
v2-0001-Fix-GenericXLogFinish.patch text/x-patch 3.7 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-09-26 23:14:15 Re: Fail hard if xlogreader.c fails on out-of-memory
Previous Message Bruce Momjian 2023-09-26 23:02:37 Re: Document that server will start even if it's unable to open some TCP/IP ports