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 14:35:35 |
Message-ID: | 16610.1472222135@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Euler Taveira | 2016-08-26 14:36:43 | Re: Renaming of pg_xlog and pg_clog |
Previous Message | Fujii Masao | 2016-08-26 14:35:16 | Re: GIN logging GIN_SEGMENT_UNMODIFIED actions? |