Re: Small proposal to improve out-of-memory messages - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Small proposal to improve out-of-memory messages
Date
Msg-id 29793.1522508918@sss.pgh.pa.us
Whole thread Raw
In response to Re: Small proposal to improve out-of-memory messages  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
Alvaro Herrera <alvherre@alvh.no-ip.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


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Online enabling of checksums
Next
From: Isaac Morland
Date:
Subject: Re: csv format for psql