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 14:35:35
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

In response to


Browse pgsql-hackers by date

  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?