From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Robert Treat <xzilla(at)users(dot)sourceforge(dot)net> |
Cc: | pgsql-hackers(at)postgresql(dot)org, Euler Taveira de Oliveira <euler(at)timbira(dot)com> |
Subject: | Re: temporary statistics option at initdb time |
Date: | 2008-08-12 17:27:55 |
Message-ID: | 48A1C81B.8060604@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Treat wrote:
> On Saturday 09 August 2008 21:31:28 Euler Taveira de Oliveira wrote:
>> Hi,
>>
>> After the Magnus patch [1], that make it possible store statistics files
>> at another (RAM-based) disk, I was thinking that would be useful to add
>> an option at initdb time to do the symlink as we already do with xlog.
>> Maybe it could be documented in monitoring.sgml too. Comments?
>>
>> [1] http://archives.postgresql.org/pgsql-hackers/2008-08/msg00176.php
>
> I find Magnus's approach to be admin un-friendly, and your patch a
> re-enforcement of that feeling. Forcing people to fall back on the OS tools
> (which may not be terribly good on systems like win32) when we could provide
> a consistent way for postgres to handle this itself seems backwards. I
> believe this would be much simpler for DBA's if we simply give them a GUC for
> stat file location, and allow them to set the location that way. Ideally this
> could be done as PGC_SIGHUP, and a change to the location would move the
> file "on-the-fly" as they say. (There might be practical limitation to making
> that work, but it would certainly be simpler for admins, imho)
Well, the general enthusiasm for this feature at all wasn't very high,
so I implemented in the least invasive way. It would certainly be
possible to do it as a GUC, and not all that much more work.
I don't think it'd be that hard to handle the SIGHUP case - just have
the stats collector start writing it in the new location the next time
it writes it out, and backends will start reading from there. There's a
short window where the backends would get no data, but I think that's
quite acceptable..
//Magnus
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-08-12 17:32:32 | Re: Transaction-controlled robustness for replication |
Previous Message | Bruce Momjian | 2008-08-12 16:54:54 | Re: Transaction-controlled robustness for replication |