From: | Antonin Houska <ah(at)cybertec(dot)at> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, 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-09-28 08:15:56 |
Message-ID: | 7764.1569658556@antos |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alvaro Herrera <alvherre(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrey Borodin | 2019-09-28 08:29:18 | Re: pglz performance |
Previous Message | Antonin Houska | 2019-09-28 08:14:25 | Re: Attempt to consolidate reading of XLOG page |