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 (pgsql-hackers@postgres
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
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 querie
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 som
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 b
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
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 some
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 tha
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
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 ou
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
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 alrea
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 backe
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 a
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.
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:
16 matches
Mail list logo