From: Antonin Houska <ah@cybertec.at>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
cc: Thomas Munro <thomas.munro@gmail.com>,
    Robert Haas <robertmhaas@gmail.com>,
    "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Subject: Re: Attempt to consolidate reading of XLOG page
In-reply-to: <20190927191736.GA13447@alvherre.pgsql>
References: <20190927191736.GA13447@alvherre.pgsql>
Comments: In-reply-to Alvaro Herrera <alvherre@2ndquadrant.com>
   message dated "Fri, 27 Sep 2019 16:17:36 -0300."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7752.1569658465.1@antos>
Content-Transfer-Encoding: quoted-printable
Date: Sat, 28 Sep 2019 10:14:25 +0200
Message-ID: <7753.1569658465@antos>
Precedence: bulk

Alvaro Herrera <alvherre@2ndquadrant.com> wrote:

> BTW that tli_p business to the openSegment callback is horribly
> inconsistent.  Some callers accept a NULL tli_p, others will outright
> crash, even though the API docs say that the callback must determine the
> timeline.  This is made more complicated by us having the TLI in "seg"
> also.  Unless I misread, the problem is again that the walsender code is
> doing nasty stuff with globals (endSegNo).  As a very minor stylistic
> point, we prefer to have out params at the end of the signature.

XLogRead() tests for NULL so it should not crash but I don't insist on doi=
ng
it this way. XLogRead() actually does not have to care whether the "open
segment callback" determines the TLI or not, so it (XLogRead) can always
receive a valid pointer to seg.ws_tli. However that in turn implies that
XLogRead() does not need the "tli" argument at all.

> > > Why do we leave this responsibility to ReadPageInternal?  Wouldn't i=
t
> > > make more sense to leave XLogRead be always responsible for setting
> > > these correctly, and remove those lines from ReadPageInternal?
> > =

> > I think there's no rule that ReadPageInternal() must use XLogRead(). I=
f we do
> > what you suggest, we need make this responsibility documented. I'll co=
nsider
> > that.

I think now we should not add any responsibility to XLogPageReadCB or its
subroutines because some extensions might already have their implementatio=
n of
XLogPageReadCB w/o XLogRead, and this change would break them.

-- =

Antonin Houska
Web: https://www.cybertec-postgresql.com