From: Antonin Houska <ah@cybertec.at>
To: Tom Lane <tgl@sss.pgh.pa.us>
cc: Alvaro Herrera <alvherre@2ndquadrant.com>,
    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: <20329.1569612518@sss.pgh.pa.us>
References: <20190927191736.GA13447@alvherre.pgsql>
 <20329.1569612518@sss.pgh.pa.us>
Comments: In-reply-to Tom Lane <tgl@sss.pgh.pa.us>
   message dated "Fri, 27 Sep 2019 15:28:38 -0400."
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <7763.1569658556.1@antos>
Date: Sat, 28 Sep 2019 10:15:56 +0200
Message-ID: <7764.1569658556@antos>
Precedence: bulk

Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> > On 2019-Sep-27, Antonin Houska wrote:
> >>> You placed the errinfo in XLogRead's stack rather than its callers' ...
> >>> I don't think that works, because as soon as XLogRead returns that
> >>> memory is no longer guaranteed to exist.
> 
> >> I was aware of this problem, therefore I defined the field as static:
> >> 
> >> +XLogReadError *
> >> +XLogRead(char *buf, XLogRecPtr startptr, Size count, TimeLineID *tli_p,
> >> +                WALOpenSegment *seg, WALSegmentContext *segcxt,
> >> +                WALSegmentOpen openSegment)
> >> +{
> >> +       char       *p;
> >> +       XLogRecPtr      recptr;
> >> +       Size            nbytes;
> >> +       static XLogReadError errinfo;
> 
> > I see.
> 
> That seems like an absolutely terrible "fix".  We don't really want
> XLogRead to be defined in a way that forces it to be non-reentrant do we?

Good point. I forgot that the XLOG reader can be used by frontends, so thread
safety is important here.

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