Reimplement nullification of walsender timestamp
authorAlvaro Herrera <alvherre@alvh.no-ip.org>
Wed, 8 Jan 2020 17:33:49 +0000 (14:33 -0300)
committerAlvaro Herrera <alvherre@alvh.no-ip.org>
Wed, 8 Jan 2020 17:33:49 +0000 (14:33 -0300)
Make the value null only at pg_stat_activity-output time, as suggested
by Tom Lane, instead of messing with the internal state.  This should
appease buildfarm members with force_parallel_mode=regress, which are
running parallel queries on logical replication walsenders.

The fact that walsenders can run parallel queries should perhaps be
studied more carefully, but for the moment let's get rid of the red
blots in buildfarm.

Backpatch to pg10, like the previous commit.

Discussion: https://postgr.es/m/30804.1578438763@sss.pgh.pa.us

src/backend/access/transam/xact.c
src/backend/utils/adt/pgstatfuncs.c

index cbc35454a7e3836268cf06effac0517b38475c74..017f03b6d8ce35d4170f38fef5cfaeb77f5b5a7f 100644 (file)
@@ -816,13 +816,6 @@ GetCurrentTransactionStopTimestamp(void)
 void
 SetCurrentStatementStartTimestamp(void)
 {
-   /*
-    * Skip if on a walsender; this is not needed, and it confuses monitoring
-    * if we publish non-NULL values.
-    */
-   if (am_walsender)
-       return;
-
    if (!IsParallelWorker())
        stmtStartTimestamp = GetCurrentTimestamp();
    else
index 99554c4d7bbad9b40286ba8ae519e48e5f937910..3dbf6048acbc5e333e1966a8b3e68fb78e781875 100644 (file)
@@ -724,7 +724,13 @@ pg_stat_get_activity(PG_FUNCTION_ARGS)
            else
                nulls[7] = true;
 
-           if (beentry->st_xact_start_timestamp != 0)
+           /*
+            * Don't expose transaction time for walsenders; it confuses
+            * monitoring, particularly because we don't keep the time up-to-
+            * date.
+            */
+           if (beentry->st_xact_start_timestamp != 0 &&
+               beentry->st_backendType != B_WAL_SENDER)
                values[8] = TimestampTzGetDatum(beentry->st_xact_start_timestamp);
            else
                nulls[8] = true;