Re: PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice() - Mailing list pgsql-hackers

From Tom Lane
Subject Re: PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()
Date
Msg-id 16610.1472222135@sss.pgh.pa.us
Whole thread Raw
In response to Re: PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
I wrote:
> After sleeping on it, I think the right answer is to introduce the new
> error-message field (and not worry about 9.5).  Will work on a patch
> for that, unless I hear objections pretty soon.

BTW, while I'm looking at this: what on god's green earth is
ThrowErrorData doing copying the supplied data into edata->assoc_context?
Surely it should be putting the data into the ErrorContext, where it's not
going to get flushed before it can be reported?  (Note that in the sole
existing use-case, edata->assoc_context is going to have been set to
CurrentMemoryContext by pq_parse_errornotice, and I see no good reason to
assume that's very long-lived ... in fact, it looks like it's whatever
happens to be active when ProcessInterrupts is called, which means there's
probably a totally separate set of problems here having to do with
potential leaks into long-lived contexts.)

I have little use for the name of that function either, as it's not
necessarily going to "throw" anything.  Maybe ReportErrorUsingData,
or something like that?
        regards, tom lane



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: GIN logging GIN_SEGMENT_UNMODIFIED actions?
Next
From: Euler Taveira
Date:
Subject: Re: Renaming of pg_xlog and pg_clog