Re: Attempt to consolidate reading of XLOG page

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Antonin Houska <ah(at)cybertec(dot)at>, 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-18 12:29:03
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On Fri, Nov 15, 2019 at 06:41:02PM -0300, Alvaro Herrera wrote:
> I don't quite understand why you backed off from switching to pread. It
> seemed a good change to me.
> [...]
> 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.

This has been quickly mentioned on the thread which has introduced

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.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-11-18 12:49:55 Re: [HACKERS] pg_shmem_allocations view
Previous Message Amit Kapila 2019-11-18 12:22:15 Re: logical decoding : exceeded maxAllocatedDescs for .spill files