On Tue, 2007-09-25 at 10:15 +0200, Csaba Nagy wrote:
> On Mon, 2007-09-24 at 10:55 -0700, Joshua D. Drake wrote:
> > IMO, monitor_ seems weird versus track_. To me monitor implies actions
> > to be taken when thresholds are met. PostgreSQL doesn't do that.
> > PostgreSQL tracks/stores information f
Am Montag, 24. September 2007 schrieb Joshua D. Drake:
> IMO, monitor_ seems weird versus track_. To me monitor implies actions
> to be taken when thresholds are met. PostgreSQL doesn't do that.
> PostgreSQL tracks/stores information for application to monitor or
> interact with and those applicati
On Mon, 2007-09-24 at 10:55 -0700, Joshua D. Drake wrote:
> IMO, monitor_ seems weird versus track_. To me monitor implies actions
> to be taken when thresholds are met. PostgreSQL doesn't do that.
> PostgreSQL tracks/stores information for application to monitor or
> interact with and those applic
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Simon Riggs wrote:
> On Mon, 2007-09-24 at 13:09 -0400, Tom Lane wrote:
>> Simon Riggs <[EMAIL PROTECTED]> writes:
>>> So it should be stats_command_string --> monitor_activity
>>> ...and the other one would be monitor_counts? OK, that fits for me.
>>
On Mon, 2007-09-24 at 13:09 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > So it should be stats_command_string --> monitor_activity
> > ...and the other one would be monitor_counts? OK, that fits for me.
>
> Are we worried about having them both singular or both plural?
> I
Simon Riggs <[EMAIL PROTECTED]> writes:
> So it should be stats_command_string --> monitor_activity
> ...and the other one would be monitor_counts? OK, that fits for me.
Are we worried about having them both singular or both plural?
I seem to recall that point coming up in the prior thread.
On Mon, 2007-09-24 at 12:50 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I'm sorry to raise this now. The earlier proposal for "track_" wasn't
> > supported by anyone that I can see, even though we decided to change the
> > way the stats parameters were arranged on those ear
Simon Riggs <[EMAIL PROTECTED]> writes:
> I'm sorry to raise this now. The earlier proposal for "track_" wasn't
> supported by anyone that I can see, even though we decided to change the
> way the stats parameters were arranged on those earlier threads.
Well, there was at least one other person wh
On Mon, 2007-09-24 at 12:51 +0200, Peter Eisentraut wrote:
> Am Montag, 24. September 2007 schrieb Simon Riggs:
> > I would personally prefer the verb "monitor" rather than track. The
> > chapter in the docs is already called "Monitoring Database Activity".
>
> What the database system does is tra
Am Montag, 24. September 2007 schrieb Simon Riggs:
> I would personally prefer the verb "monitor" rather than track. The
> chapter in the docs is already called "Monitoring Database Activity".
What the database system does is tracking. Then you use an administrator or
Nagios to monitor the resul
On Sun, 2007-09-23 at 12:51 -0400, Tom Lane wrote:
> Personally I would favor
>
> track_activities
> track_counts
I would personally prefer the verb "monitor" rather than track. The
chapter in the docs is already called "Monitoring Database Activity".
Sysadmins know t
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Actually ... does stats_reset_on_server_start have a reason to live
>> at all?
> We also have a stats reset after recovery, and a function to reset it at
> the user's whim, so I agree that there doesn't seem to be any reason to
> keep
Am Sonntag, 23. September 2007 schrieb Tom Lane:
> Actually ... does stats_reset_on_server_start have a reason to live
> at all?
Kill it. It never made much sense to me anyway.
--
Peter Eisentraut
http://developer.postgresql.org/~petere/
---(end of broadcast)---
Tom Lane wrote:
> I wrote:
> > There wasn't any discussion of renaming stats_reset_on_server_start,
> > though logical consistency would seem to require this if we choose
> > a name not starting with stats_ for $merged_var.
>
> Actually ... does stats_reset_on_server_start have a reason to live
>
I wrote:
> There wasn't any discussion of renaming stats_reset_on_server_start,
> though logical consistency would seem to require this if we choose
> a name not starting with stats_ for $merged_var.
Actually ... does stats_reset_on_server_start have a reason to live
at all? It hardly seems like
[ just when you thought it was safe to go back in the water ]
In threads starting here and here:
http://archives.postgresql.org/pgsql-hackers/2007-07/msg00874.php
http://archives.postgresql.org/pgsql-hackers/2007-08/msg00043.php
I believe we had reached consensus on the following points:
* log_au
16 matches
Mail list logo
