Re: PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()
Date: 2016-08-26 18:28:41
Message-ID: 6387.1472236121@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Aug 26, 2016 at 11:26 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I'm not quite sure what to do about this. It feels a tad wrong to use
>> ErrorContext as the active context during HandleParallelMessages, but
>> what else should we use? Maybe this needs its very own private context
>> that we can reset after each use?

> If we use ErrorContext, will anything go wrong?

I think it might, if we were unlucky enough to be doing this while the
leader was engaged in reporting some other error for its own reasons.
To avoid accumulated memory leakage over multiple worker error reports,
we ought to do a MemoryContextReset at the start or end (probably start)
of HandleParallelMessages, and that would be problematic if ErrorContext
had some data in it already. It's possible that the scenario can't occur
because CHECK_FOR_INTERRUPTS is never done inside error processing, but
I would not feel very comfortable with that assumption.

I'm thinking a dedicated context is the way to go. It won't take very
much code.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2016-08-26 18:34:27 old_snapshot_threshold documentation
Previous Message Robert Haas 2016-08-26 18:03:56 Re: PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()