Decibel! wrote: > On Aug 13, 2008, at 4:12 AM, Magnus Hagander wrote: >> Tom Lane wrote: >>> Decibel! <[EMAIL PROTECTED]> 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. :-) //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers