Re: temporary statistics option at initdb time

Magnus Hagander wrote:
> Decibel! wrote:
>> On Aug 13, 2008, at 4:12 AM, Magnus Hagander wrote:
>>> Tom Lane wrote:
>>>> Decibel! <decibel(at)decibel(dot)org> writes:
>>>>> I disagree. While we don't guarantee stats are absolutely up-to-date,
>>>>> or atomic I don't think that gives license for them to just magically
>>>>> not exist sometimes.
>>>>> Would it really be that hard to have the system copy the file out
>>>>> before telling all the other backends of the change?
>>>> Well, there is no (zero, zilch, nada) use-case for changing this setting
>>>> on the fly. Why not make it a "frozen at postmaster start" GUC? Seems
>>>> like that gets all the functionality needed and most of the ease of use.
>>> Oh, there is a use-case. If you run your system and then only afterwards
>>> realize the I/O from the stats file is high enough to be an issue, and
>>> want to change it.
>>>
>>> That said, I'm not sure the use-case is anywhere near common enough to
>>> put a lot of code into it.
>>
>> Something to keep in mind as PG is used to build larger systems 'further
>> up the enterprise'... for us to bounce a database at work costs us a LOT
>> in lost revenue. I don't want to go into specifics, but it's more than
>> enough to buy a very nice car. :) That's why I asked how hard it'd be to
>> do this on the fly.
>
> Well, it's doable, but fairly hard.
>
> But you can do it the symlink way without shutting it down, I think. :-)

Actually, I think maybe not so hard. Attached is a patch that fixes
this. It's done by keeping the old filename around. When you change the
path, the stats collector will start writing the new file the next time
it writes something (which should be max 0.5 seconds later if something
is happening). The backends will immediately try to read from the new
filename, but if that one is not found, they will switch to reading the
old filename. This obviously fails if you change the temp directory
twice in less than half a second, but I really don't see a use-case for
that...

Or did I miss something here? :-)

//Magnus