Re: XLogWrite uses palloc within a critical section

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

In response to

Responses

Browse pgsql-hackers by date

  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 ..