Re: Small proposal to improve out-of-memory messages

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Small proposal to improve out-of-memory messages
Date: 2018-03-31 15:08:38
Message-ID: 29793.1522508918@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> Tom Lane wrote:
>> In the wake of commit 442accc3f one might think that the message should
>> also include the context "identifier" if any. But I'm specifically not
>> proposing that, because of the point made in the discussion of that patch
>> that some identifier strings might contain security-sensitive query
>> excerpts. Now that that commit has required all context "names" to be
>> compile-time constants, it's hard to see how there could be any security
>> downside to showing them in a user-visible message.

> How about using errdetail_log() to include the context identifier?

Not really excited about that; we have no field experience to say it'd
be useful. If we start finding ourselves asking "exactly which ExprState
was that", we could revisit the question perhaps.

Furthermore, because elog.c constructs the whole detail string in
ErrorContext, doing this would create a significant OOM hazard anytime
the context ID didn't fit into the preallocated ErrorContext space.
Context names are generally short enough that they're not adding to
our risk there, but the ID strings could be very long in some cases.
(mcxt.c avoids this hazard by writing directly to stderr, but elog.c
can't do that.)

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Isaac Morland 2018-03-31 15:22:43 Re: csv format for psql
Previous Message Magnus Hagander 2018-03-31 15:05:28 Re: Online enabling of checksums