Re: PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()
От | Tom Lane |
---|---|
Тема | Re: PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice() |
Дата | |
Msg-id | 16610.1472222135@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice() (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PG_DIAG_SEVERITY and a possible bug in pq_parse_errornotice()
|
Список | 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 по дате отправления: