Re: Attempt to consolidate reading of XLOG page

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: Attempt to consolidate reading of XLOG page
Дата
Msg-id 20190927191736.GA13447@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: Attempt to consolidate reading of XLOG page  (Antonin Houska <ah@cybertec.at>)
Ответы Re: Attempt to consolidate reading of XLOG page  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Attempt to consolidate reading of XLOG page  (Antonin Houska <ah@cybertec.at>)
Re: Attempt to consolidate reading of XLOG page  (Antonin Houska <ah@cybertec.at>)
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Mike Palmiotto
Дата:
Сообщение: Re: Hooks for session start and end, take two
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Improving on MAX_CONVERSION_GROWTH