I committed this with minor tweaks to avoid having to scan the
registered workers list on each registration. Opinions on this error
report are still welcome:
> + ereport(LOG,
> +
> (errcode(ERRCODE_CONFIGURATION_LIMIT_EXCEEDED),
> +
Heikki Linnakangas wrote:
> On 27.12.2012 22:46, Alvaro Herrera wrote:
> >Heikki Linnakangas wrote:
> >
> >>Might be cleaner to directly assign the correct value to MaxBackends
> >>above, ie. "MaxBackends = MaxConnections + newval + 1 +
> >>GetNumShmemAttachedBgworkers()". With a comment to remind
On 27.12.2012 22:46, Alvaro Herrera wrote:
Heikki Linnakangas wrote:
Might be cleaner to directly assign the correct value to MaxBackends
above, ie. "MaxBackends = MaxConnections + newval + 1 +
GetNumShmemAttachedBgworkers()". With a comment to remind that it
needs to be kept in sync with the
Andres Freund writes:
> On 2012-12-27 18:44:57 -0500, Tom Lane wrote:
>> This is broken whether it's EXEC_BACKEND or not: you don't get to change
>> anything that determines the number of workers post-startup.
>> num_workers should have been declared PGC_POSTMASTER.
> Well, the problem is, a shar
Tom Lane schrieb:
>Andres Freund writes:
>> I am still worried about the following scenario in the EXEC_BACKEND
>case:
>
>> 1) postmaster starts
>> 2) reads config
>> 3) executes _PG_init for shared_preload_libraries
>> 4) library 'abc' gets config value 'abc.num_workers = 2' and
>registers as
On 2012-12-27 18:44:57 -0500, Tom Lane wrote:
> Andres Freund writes:
> > I am still worried about the following scenario in the EXEC_BACKEND case:
>
> > 1) postmaster starts
> > 2) reads config
> > 3) executes _PG_init for shared_preload_libraries
> > 4) library 'abc' gets config value 'abc.num_w
Andres Freund writes:
> I am still worried about the following scenario in the EXEC_BACKEND case:
> 1) postmaster starts
> 2) reads config
> 3) executes _PG_init for shared_preload_libraries
> 4) library 'abc' gets config value 'abc.num_workers = 2' and registers as
> many workers
> 5) some time
On 2012-12-27 20:06:07 +0200, Heikki Linnakangas wrote:
> On 27.12.2012 19:15, Alvaro Herrera wrote:
> >I committed background workers three weeks ago, claiming it worked on
> >EXEC_BACKEND, and shortly thereafter I discovered that it didn't. I
> >noticed that the problem is the kludge to cause po
Heikki Linnakangas wrote:
> Might be cleaner to directly assign the correct value to MaxBackends
> above, ie. "MaxBackends = MaxConnections + newval + 1 +
> GetNumShmemAttachedBgworkers()". With a comment to remind that it
> needs to be kept in sync with the other places where that
> calculation
Stephen Frost writes:
> 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
>> itsel
Stephen Frost wrote:
> * Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> > Thinking about this some more, it might be cleaner to move the
> > responsibility of setting MaxBackends out of guc.c, into
> > postmaster.c. The guc machinery would set max_connections and
> > autovacuum_max_workers a
On 27 December 2012 18:36, Stephen Frost wrote:
> 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 mi
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 i
On 27 December 2012 18:06, Heikki Linnakangas 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
* Heikki Linnakangas (hlinnakan...@vmware.com) wrote:
> Thinking about this some more, it might be cleaner to move the
> responsibility of setting MaxBackends out of guc.c, into
> postmaster.c. The guc machinery would set max_connections and
> autovacuum_max_workers as usual, but not try to set Max
On 27.12.2012 19:15, Alvaro Herrera wrote:
I committed background workers three weeks ago, claiming it worked on
EXEC_BACKEND, and shortly thereafter I discovered that it didn't. I
noticed that the problem is the kludge to cause postmaster and children
to recompute MaxBackends after shared_prelo
On Thu, Dec 27, 2012 at 6:15 PM, Alvaro Herrera
wrote:
> I committed background workers three weeks ago, claiming it worked on
> EXEC_BACKEND, and shortly thereafter I discovered that it didn't. I
> noticed that the problem is the kludge to cause postmaster and children
> to recompute MaxBackends
I committed background workers three weeks ago, claiming it worked on
EXEC_BACKEND, and shortly thereafter I discovered that it didn't. I
noticed that the problem is the kludge to cause postmaster and children
to recompute MaxBackends after shared_preload_libraries is processed; so
the minimal fix
18 matches
Mail list logo
