From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: XLogWrite uses palloc within a critical section |
Date: | 2018-05-25 06:05:21 |
Message-ID: | 466a3c6d-7986-8cb1-d908-e85aa6a090e0@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Aleksandr Parfenov | 2018-05-25 06:23:15 | Re: [GSoC] github repo and initial work |
Previous Message | Thomas Munro | 2018-05-25 05:58:41 | Re: [HACKERS] lseek/read/write overhead becomes visible at scale .. |