Reimplement nullification of walsender timestamp
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
This commit is contained in:
parent
c24f3b70ef
commit
20c4df8c8d
@ -817,13 +817,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
|
||||
|
@ -726,7 +726,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;
|
||||
|
Loading…
x
Reference in New Issue
Block a user