On 3 December 2015 at 04:22, Julian Schauder <[email protected]>
wrote:
> I suggest adding a new state to pg_stat_activity.state for backends that
> are
>
waiting for their synchronous commit to be flushed on the remote host.
>
>
Excellent idea. Anything that improves management and visibility into what
the system is doing like this is really valuable.
I notice that you don't set the 'waiting' flag. 'waiting' is presently
documented as:
<entry>True if this backend is currently waiting on a lock</entry>
... but I'm inclined to just widen its definition and set it here, since we
most certainly are waiting, and the column isn't named 'waiting_on_a_lock'.
It shouldn't upset various canned lock monitoring queries people have since
they generally do an inner join on pg_locks anyway.
There are no test changes in this patch, but that's reasonable because we
don't currently have a way to automate tests of sync rep.
I've attached a patch with minor wording/formatting changes, but I think
I'd like to change 'waiting' to true as well. Opinions?
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From e0bcab8ec199e92aaf51ac732275f1a2a5f1eb9f Mon Sep 17 00:00:00 2001
From: Craig Ringer <[email protected]>
Date: Thu, 3 Dec 2015 07:57:59 +0800
Subject: [PATCH] Add 'waiting for replication' state to pg_stat_activity
---
doc/src/sgml/monitoring.sgml | 5 +++++
src/backend/replication/syncrep.c | 14 +++++++++++++-
src/backend/utils/adt/pgstatfuncs.c | 3 +++
src/include/pgstat.h | 1 +
4 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index e64b7ef..458ae0f 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -642,6 +642,11 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
</listitem>
<listitem>
<para>
+ <literal>waiting for synchronous replication</>: The backend is waiting for its transaction to be flushed on a synchronous standby.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
<literal>idle</>: The backend is waiting for a new client command.
</para>
</listitem>
diff --git a/src/backend/replication/syncrep.c b/src/backend/replication/syncrep.c
index 325239d..f2bf5e1 100644
--- a/src/backend/replication/syncrep.c
+++ b/src/backend/replication/syncrep.c
@@ -45,7 +45,7 @@
#include "postgres.h"
#include <unistd.h>
-
+#include <pgstat.h>
#include "access/xact.h"
#include "miscadmin.h"
#include "replication/syncrep.h"
@@ -153,6 +153,18 @@ SyncRepWaitForLSN(XLogRecPtr XactCommitLSN)
}
/*
+ * Alter 'state' in pg_stat before entering the loop.
+ *
+ * As with updating the ps display it is safe to assume that we'll wait
+ * at least for a short time so we just set the state without bothering
+ * to check if we're really going to have to wait for the standby.
+ *
+ * We don't set the 'waiting' flag because that's documented as waiting
+ * on a lock.
+ */
+ pgstat_report_activity(STATE_WAITINGFORREPLICATION,NULL);
+
+ /*
* Wait for specified LSN to be confirmed.
*
* Each proc has its own wait latch, so we perform a normal latch
diff --git a/src/backend/utils/adt/pgstatfuncs.c b/src/backend/utils/adt/pgstatfuncs.c
index f7c9bf6..84d67e0 100644
--- a/src/backend/utils/adt/pgstatfuncs.c
+++ b/src/backend/utils/adt/pgstatfuncs.c
@@ -663,6 +663,9 @@ pg_stat_get_activity(PG_FUNCTION_ARGS)
case STATE_IDLEINTRANSACTION_ABORTED:
values[4] = CStringGetTextDatum("idle in transaction (aborted)");
break;
+ case STATE_WAITINGFORREPLICATION:
+ values[4] = CStringGetTextDatum("waiting for synchronous replication");
+ break;
case STATE_DISABLED:
values[4] = CStringGetTextDatum("disabled");
break;
diff --git a/src/include/pgstat.h b/src/include/pgstat.h
index 9ecc163..ab1befc 100644
--- a/src/include/pgstat.h
+++ b/src/include/pgstat.h
@@ -692,6 +692,7 @@ typedef enum BackendState
STATE_IDLEINTRANSACTION,
STATE_FASTPATH,
STATE_IDLEINTRANSACTION_ABORTED,
+ STATE_WAITINGFORREPLICATION,
STATE_DISABLED
} BackendState;
--
2.1.0
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
