Simon, * Simon Riggs (si...@2ndquadrant.com) wrote: > 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.
I agree that the current implementation could lead to problems/confusion
for contrib module authors, if they're doing something with MaxBackends.
> 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?
Before we go there, I'm honestly curious to hear what the use case is
for a contrib module to need that information, particularly at _init
time..? Also, would we need every contrib module to add in that call?
What if they don't create any additional bgworkers? What if they do but
don't provide the API call? I wonder if max_connections, which is well
defined and not subject to other modules or other things happening,
might be a better value to encourage authors to use, if they're looking
for some heuristic for how many possible backends there could be?
> That way we'd know the final value and everybody would have the
> correct value at init time.
This sounds like an opportunity for people to add another backend worker
and then forget to update what they tell the postmaster and everyone
else about how many backend workers they're going to create.. Or maybe
having a larger value be returned than they actually use.
Thanks,
Stephen
signature.asc
Description: Digital signature
