Re: Attempt to consolidate reading of XLOG page

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Antonin Houska <ah(at)cybertec(dot)at>, 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:28:38
Message-ID: 20329.1569612518@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2019-09-27 19:35:33 Re: recovery starting when backup_label exists, but not recovery.signal
Previous Message legrand legrand 2019-09-27 19:26:31 Re: Hooks for session start and end, take two