Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
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
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think this is introducing complication and race conditions to solve a
problem that no one will really care about. Just let people change the
filename at SIGHUP and document that doing that on-the-fly may cause
stats queries to fail
Tom Lane wrote:
Magnus Hagander [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think this is introducing complication and race conditions to solve a
problem that no one will really care about. Just let people change the
filename at SIGHUP and document that doing that on-the-fly may cause
stats
I wrote:
[ squint... ] Actually, it looks like the stats collector SIG_IGNores
SIGHUP? That can't be right (any more) can it?
Oh, never mind, I see my hour-old CVS pull is obsolete ...
regards, tom lane
--
Sent via pgsql-hackers mailing list
Magnus Hagander wrote:
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
Magnus Hagander [EMAIL PROTECTED] writes:
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
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
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
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
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
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.
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
On Aug 12, 2008, at 12:27 PM, Magnus Hagander wrote:
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
Robert Treat escreveu:
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
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
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]
16 matches
Mail list logo
