Re: XLogWrite uses palloc within a critical section - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: XLogWrite uses palloc within a critical section
Date
Msg-id 466a3c6d-7986-8cb1-d908-e85aa6a090e0@iki.fi
Whole thread Raw
In response to XLogWrite uses palloc within a critical section  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: XLogWrite uses palloc within a critical section  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
List pgsql-hackers
On 25/05/18 07:45, Kyotaro HORIGUCHI wrote:
> Hello.
> 
> I happened to see the following in XLogWrite.
> 
>>   ereport(PANIC,
>>       (errcode_for_file_access(),
>>        errmsg("could not seek in log file %s to offset %u: %m",
>>           XLogFileNameP(ThisTimeLineID, openLogSegNo),
>>           startoffset)));
> 
> where XLogFileNameP calls palloc within, and it is within a
> critical section there. So it ends with assertion failure hiding
> the PANIC message. We should use XLogFileName instead. The
> problem has existed at least since 9.3. The code is frequently
> revised so the patch needed to vary into four files.

Hmm, that's rather annoying, it sure would be handy if we could do small 
palloc()s like this in error messages safely.

I wonder if we could switch to ErrorContext in errstart()? That way, any 
small allocations in the ereport() arguments, like what XLogFileNameP() 
does, would be allocated in ErrorContext.

- Heikki


pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] lseek/read/write overhead becomes visible at scale ..
Next
From: Aleksandr Parfenov
Date:
Subject: Re: [GSoC] github repo and initial work