Skip to content
Browse files

Revisions to docs per Steve's comments

  • Loading branch information...
1 parent c6082bc commit 72ed0337641eefda095cfcb706562d71d9c03413 Christopher Browne committed
Showing with 22 additions and 18 deletions.
  1. +4 −15 doc/adminguide/monitoring.sgml
  2. +7 −0 doc/adminguide/prerequisites.sgml
  3. +11 −3 src/slon/monitor_thread.c
View
19 doc/adminguide/monitoring.sgml
@@ -528,23 +528,12 @@ becoming a repetitive recursive activity.</para></listitem>
<listitem><para> Timestamps are based on the clock time of the &lslon;
process.</para>
-<para> It might seem somewhat desirable for the database to record
-DB-centred timestamps, unfortunately that would only be the correct
-time if each thread were responsible for stowing its own activities in
-&slcomponents; in the database. This would multiply database
-activity, and the implementation instead passes requests to a single
-thread that uses a single DB connection to record things, with the
-consequence that timestamps must be captured based on the system clock
-of the &lslon; process. </para>
-
<para> In order for the timestamps to be accurate, it is important to
use NTP or similar technology to keep servers' clocks synchronized, as
-recommended in <xref linkend="requirements">.</para>
-
-<para> If the host where a &lslon; runs has its time significantly out
-of sync with the database that it manages, queries against
-&slcomponents; may provide results that will confuse the
-reader.</para>
+recommended in <xref linkend="requirements">. If the host where a
+&lslon; runs has its time significantly out of sync with the database
+that it manages, queries against &slcomponents; may provide results
+that will confuse the reader.</para>
</listitem>
<listitem><para> process.</para> </listitem>
View
7 doc/adminguide/prerequisites.sgml
@@ -42,8 +42,15 @@ timestamps sourced from multiple servers.</para></listitem>
<listitem><para>Monitoring table &slcomponents; captures timestamps
based on the clock time on the host running &lslon;.</para></listitem>
+<listitem><para> &lslon; logs are likely to contain
+timestamps.</para></listitem>
+
</itemizedlist>
+<para> Figuring out what is going on is likely to be made rather
+confusing if the database servers and servers where &lslon; instances
+run do not agree on what time it its. </para>
+
</listitem>
<listitem><para>A reliable network between nodes</para>
View
14 src/slon/monitor_thread.c
@@ -5,8 +5,6 @@
*
* Copyright (c) 2011, PostgreSQL Global Development Group
* Author: Christopher Browne, Afilias Canada
- *
- *
*-------------------------------------------------------------------------
*/
@@ -43,7 +41,7 @@ int monitor_interval;
/* ----------
* slon_localMonitorThread
*
- * Monitoring thread that periodically flushes stackd-up monitoring requests to database
+ * Monitoring thread that periodically flushes stacked-up monitoring requests to database
* ----------
*/
void *
@@ -307,6 +305,16 @@ monitor_state(char *actor, int node, pid_t conn_pid, /* @null@ */ char *activity
tos->node = node;
tos->conn_pid = conn_pid;
tos->event = event;
+
+/* It might seem somewhat desirable for the database to record
+ * DB-centred timestamps, unfortunately that would only be the
+ * correct time if each thread were responsible for stowing its own
+ * activities in sl_components in the database. This would multiply
+ * database activity, and the implementation instead passes requests
+ * to a single thread that uses a single DB connection to record
+ * things, with the consequence that timestamps must be captured
+ * based on the system clock of the slon process. */
+
tos->start_time = time(NULL);
if (actor != NULL)
{

0 comments on commit 72ed033

Please sign in to comment.
Something went wrong with that request. Please try again.