| From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
|---|---|
| To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
| Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: fix bgworkers in EXEC_BACKEND |
| Date: | 2012-12-27 18:17:58 |
| Message-ID: | CA+U5nM+60Hwxih8ycw+Q-hXjAF8h+VLUPS1GatS5Dy3MCnnLQg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 27 December 2012 18:06, Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> wrote:
> This would have the advantage that MaxBackends would be kept set at zero,
> until we know the final value. That way it's obvious that you cannot trust
> the value of MaxBackends in a contrib module preload-function, for example,
> which would reduce the chance of programmer mistakes.
I admire your forward thinking on that; yes, that could cause
problems. But even then, we would be admitting that nobody now gets a
valid value of MaxBackends, which sounds like it might be a problem in
itself.
Perhaps we should try to solve that a different way? Can we ask for
reservations of bgworkers ahead of running their _init functions,
using an additional API call?
That way we'd know the final value and everybody would have the
correct value at init time.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2012-12-27 18:36:43 | Re: fix bgworkers in EXEC_BACKEND |
| Previous Message | Stephen Frost | 2012-12-27 18:16:21 | Re: fix bgworkers in EXEC_BACKEND |