| From: | Andres Freund <andres(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Antonin Houska <antonin(dot)houska(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: bgworker crashed or not? |
| Date: | 2014-04-16 16:00:47 |
| Message-ID: | 20140416160047.GM17874@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2014-04-16 11:54:25 -0400, Tom Lane wrote:
> Andres Freund <andres(at)2ndquadrant(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2014-04-16 16:01:36 | Re: PostgreSQL in Windows console and Ctrl-C |
| Previous Message | Tom Lane | 2014-04-16 15:54:25 | Re: bgworker crashed or not? |