Re: xact_start for walsender & logical decoding not updated

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: pgsql-hackers@postgresql.org
Date: 2019-12-10T00:04:40Z
Lists: pgsql-hackers
Hi,

On 2019-12-10 00:44:09 +0100, Tomas Vondra wrote:
> I think there's a minor bug in pg_stat_activity tracking of walsender
> processes. The issue is that xact_start is only updated at the very
> beginning when the walsender starts (so it's almost exactly equal to
> backend_start) and then just flips between NULL and that value.
> 
> Reproducing this is trivial - just create a publication/subscription
> with the built-in logical replication, and run arbitrary workload.
> You'll see that the xact_start value never changes.
> 
> I think the right fix is calling SetCurrentStatementStartTimestamp()
> right before StartTransactionCommand() in ReorderBufferCommit, per the
> attached patch.

> -- 
> Tomas Vondra                  http://www.2ndQuadrant.com
> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

> diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication/logical/reorderbuffer.c
> index 53affeb877..5235fb31b8 100644
> --- a/src/backend/replication/logical/reorderbuffer.c
> +++ b/src/backend/replication/logical/reorderbuffer.c
> @@ -1554,7 +1554,10 @@ ReorderBufferCommit(ReorderBuffer *rb, TransactionId xid,
>  		if (using_subtxn)
>  			BeginInternalSubTransaction("replay");
>  		else
> +		{
> +			SetCurrentStatementStartTimestamp();
>  			StartTransactionCommand();
> +		}

I'm quite doubtful this is useful. To me this seems to do nothing but
add the overhead of timestamp computation - which isn't always that
cheap. I don't think you really can draw meaning from this?

Greetings,

Andres Freund



Commits

  1. Reimplement nullification of walsender timestamp

  2. pg_stat_activity: show NULL stmt start time for walsenders