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 |
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 |