Re: Attempt to consolidate reading of XLOG page - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Attempt to consolidate reading of XLOG page
Date
Msg-id 20191120083802.GB47145@paquier.xyz
Whole thread Raw
In response to Re: Attempt to consolidate reading of XLOG page  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On Mon, Nov 18, 2019 at 09:29:03PM +0900, Michael Paquier wrote:
> Now, read() > pread() > read()+lseek(), and we don't actually need to
> seek into the file for all the cases where we read a WAL page.  And on
> a platform which uses the fallback implementation, this increases the
> number of lseek() calls.  I can see as you say that using it directly
> in the refactoring can simplify the code.

Putting this point aside, here is the error coming from
contrib/test_decoding/, and this is independent of Alvaro's changes:
+ERROR:  invalid magic number 0000 in log segment
000000010000000000000001, offset 6905856

I don't think that this is just xlp_magic messed up, the full page
read is full of zeros.  But that's just a guess.

Looking at the code, I am spotting one inconsistency in the way
seg->ws_off is compiled after doing the read on the new version
compared to the three others.  read() would move the offset of the
file, but the code is forgetting to increment it by a amount of
readbytes.  Isn't that incorrect?

A second thing is that wal_segment_open() definition is incorrect in
xlogutils.c, generating a warning.  The opened fd is the returned
result, and not an argument of the routine.

I am switching the patch as waiting on author.  Antonin, could you
look at those problems?
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Amit Khandekar
Date:
Subject: Re: logical decoding : exceeded maxAllocatedDescs for .spill files
Next
From: Amit Khandekar
Date:
Subject: Re: logical decoding : exceeded maxAllocatedDescs for .spill files