Re: Attempt to consolidate reading of XLOG page

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Antonin Houska <ah(at)cybertec(dot)at>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Attempt to consolidate reading of XLOG page
Date: 2019-11-15 21:41:02
Message-ID: 20191115214102.GA15616@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-Nov-12, Antonin Houska wrote:

> ok, the next version uses explicit lseek(). Maybe the fact that XLOG is mostly
> read sequentially (i.e. without frequent seeks) is the reason pread() has't
> been adopted so far.

I don't quite understand why you backed off from switching to pread. It
seemed a good change to me.

Here's a few edits on top of your latest.

The new routine WALRead() is not at all the same as the previous
XLogRead, so I don't see why we would keep the name. Hence renamed.

I see no reason for the openSegment callback to return the FD in an out
param instead of straight return value. Changed that way.

Having seek/open be a boolean "xlr_seek" seems a bit weird. Changed to
an "operation" enum. (Maybe if we go back to pg_pread we can get rid of
this.) Accordingly, change WALReadRaiseError and WALDumpReadPage.

Change xlr_seg to be a struct rather than pointer to struct. It seems a
bit dangerous to me to return a pointer that we don't know is going to
be valid at raise-error time. Struct assignment works fine for the
purpose.

Renamed XLogDumpReadPage to WALDumpReadPage, because what the heck is
XLogDump anyway? That doesn't exist.

I would only like to switch this back to pg_pread() (from seek/read) and
I'd be happy to commit this.

What is logical_read_local_xlog_page all about? Seems useless. Let's
get rid of it.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2019-11-15 21:41:45 Re: Attempt to consolidate reading of XLOG page
Previous Message Thomas Munro 2019-11-15 21:32:14 Re: PHJ file leak.