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 that it
needs
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
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
On Thu, Dec 27, 2012 at 6:15 PM, Alvaro Herrera
alvhe...@2ndquadrant.com 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
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
* 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
On 27 December 2012 18:06, Heikki Linnakangas hlinnakan...@vmware.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
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
On 27 December 2012 18:36, Stephen Frost sfr...@snowman.net 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
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 as usual,
Stephen Frost sfr...@snowman.net 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
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 is
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
Andres Freund and...@2ndquadrant.com 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
On 2012-12-27 18:44:57 -0500, Tom Lane wrote:
Andres Freund and...@2ndquadrant.com 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
Tom Lane t...@sss.pgh.pa.us schrieb:
Andres Freund and...@2ndquadrant.com 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
Andres Freund and...@2ndquadrant.com 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
18 matches
Mail list logo
