| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Noah Misch <noah(at)leadboat(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: error handling in RegisterBackgroundWorker |
| Date: | 2017-04-11 14:56:19 |
| Message-ID: | eb2499c1-3222-060d-796d-f970e2c8b8fa@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 4/10/17 23:22, Tom Lane wrote:
> Personally I'd err on the side of "starting up degraded is better than
> not starting at all". Or maybe we should invent a GUC to let DBAs
> express their preference on that?
If we defaulted allow_degraded to yes, then users wouldn't find that
setting until they do start up degraded and want to fix things, in which
case they could just fix the settings that caused the degraded startup
in the first place.
If we defaulted to no, then I don't think any user would go in and
change it. "Sure, I'll allow degraded startup. That sounds useful."
I think there is no clear agreement here, and no historically consistent
behavior. I'm prepared to let it go and cross it off the list of open
items. I believe we should keep thinking about it, but it's not
something that has to hold up beta.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Fujii Masao | 2017-04-11 15:12:16 | Re: max_sync_workers_per_subscription is missing in postgresql.conf |
| Previous Message | Jeff Davis | 2017-04-11 14:46:20 | Re: Merge join for GiST |