From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)2ndquadrant(dot)com> |
Cc: | pgsql-committers(at)postgresql(dot)org |
Subject: | Re: pgsql: Again fix initialization of auto-tuned effective_cache_size. |
Date: | 2014-05-06 17:32:02 |
Message-ID: | 956.1399397522@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
Andres Freund <andres(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2014-05-06 17:44:47 | pgsql: Fix logic bug in dsm_attach(). |
Previous Message | Bruce Momjian | 2014-05-06 16:21:20 | Re: pgsql: Properly detect read and write errors in pg_dump/dumpall, and pg |