Re: bgworker crashed or not?
От | Andres Freund |
---|---|
Тема | Re: bgworker crashed or not? |
Дата | |
Msg-id | 20140416160047.GM17874@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: bgworker crashed or not? (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: bgworker crashed or not?
|
Список | pgsql-hackers |
On 2014-04-16 11:54:25 -0400, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On 2014-04-16 11:37:47 -0400, Robert Haas wrote: > >> Why can't that be handled through ereport(ERROR/FATAL) rather than > >> through the choice of exit status? > > > I dislike that because it essentially requires the bgworker to have a > > full error catching environment like PostgresMain() has. That seems > > bad for many cases. > > That sounds like utter nonsense. No sane bgwriter code is going to be > able to discount the possibility of something throwing an elog(ERROR). > Now, you might not need the ability to do a transaction abort, but > you'll have to at least be able to terminate the process cleanly. Why? Throwing an error without an exception stack seems to work sensibly? The error is promoted to FATAL and the normal FATAL handling is performed? C.f. pg_re_throw() called via errfinish() in the ERRROR case. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: