pgsql: Again fix initialization of auto-tuned effective_cache_size.

Hi,

On 2014-03-20 16:58:42 +0000, Tom Lane wrote:

Again fix initialization of auto-tuned effective_cache_size.

The previous method was overly complex and underly correct; in particular,
by assigning the default value with PGC_S_OVERRIDE, it prevented later
attempts to change the setting in postgresql.conf, as noted by Jeff Janes.
We should just assign the default value with source PGC_S_DYNAMIC_DEFAULT,
which will have the desired priority relative to the boot_val as well as
user-set values.

There is still a gap in this method: if there's an explicit assignment of
effective_cache_size = -1 in the postgresql.conf file, and that assignment
appears before shared_buffers is assigned, the code will substitute 4 times
the bootstrap default for shared_buffers, and that value will then persist
(since it will have source PGC_S_FILE). I don't see any very nice way
to avoid that though, and it's not a case to be expected in practice.
The existing comments in guc-file.l look forward to a redesign of the
DYNAMIC_DEFAULT mechanism; if that ever happens, we should consider this
case as one of the things we'd like to improve.

This still is pretty ugly. Couldn't we just have a function in
costsize.c that returns the actual value and computes it based on
NBuffers if set to -1? Which is also called by a show_hook?

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers

Andres Freund <andres@2ndquadrant.com> writes:

On 2014-03-20 16:58:42 +0000, Tom Lane wrote:

Again fix initialization of auto-tuned effective_cache_size.

This still is pretty ugly. Couldn't we just have a function in
costsize.c that returns the actual value and computes it based on
NBuffers if set to -1? Which is also called by a show_hook?

I agree that it's ugly, but what you're suggesting would have failure
modes of its own. For example, reading out the value and then
re-assigning what that says would change the actual stored value from -1
to something else, resulting in the value ceasing to track the underlying
GUC.

In the particular example at hand, that might not matter, since
shared_buffers can't change anymore after the initial read of
postgresql.conf. But it's certainly no good as a prototype solution for
other GUCs, which I think is the main criterion for ugliness here.

Basically, we do not have a good design for GUCs whose default is supposed
to change based on other GUCs. I'd like to see that addressed in a more
general fashion, but I don't know what the solution will be.

Perhaps the real short-term question is whether we should revert this
whole change in effective_cache_size's behavior until we do have that
better design.

regards, tom lane

--
Sent via pgsql-committers mailing list (pgsql-committers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-committers