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: 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-27 19:17:36
Message-ID: 20190927191736.GA13447@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

> > You need to allocate the struct in the callers stacks and pass its address
> > to XLogRead. XLogRead can return NULL if everything's okay or the pointer
> > to the errinfo struct.
>
> I didn't choose this approach because that would add one more argument to the
> function.

Yeah, the signature does seem a bit unwieldy. But I wonder if that's
too terrible a problem, considering that this code is incurring a bunch
of syscalls in the best case anyway.

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.

> > Why do we leave this responsibility to ReadPageInternal? Wouldn't it
> > 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(). If we do
> what you suggest, we need make this responsibility documented. I'll consider
> that.

Hmm. Thanks.

> > (BTW "is called by the XLOG reader" is a bit strange in code that appears in
> > xlogreader.c).
>
> ok, "called by XLogPageReadCB callback" would be more accurate. Not sure if
> we'll eventually need this phrase in the comment at all.

I think that would be slightly clearer. But if we can force this code
into actually making sense, that would be much better.

--
Á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 Tom Lane 2019-09-27 19:25:02 Re: Improving on MAX_CONVERSION_GROWTH
Previous Message Mike Palmiotto 2019-09-27 19:01:39 Re: Hooks for session start and end, take two