Re: xact_start for walsender & logical decoding not updated - Mailing list pgsql-hackers

From Craig Ringer
Subject Re: xact_start for walsender & logical decoding not updated
Date
Msg-id CAMsr+YHSdOev0ctrApJwa7T3Fjtfd5QVBMN84m4ax4oT6ctM8w@mail.gmail.com
Whole thread Raw
In response to Re: xact_start for walsender & logical decoding not updated  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Responses Re: xact_start for walsender & logical decoding not updated  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers
On Wed, 11 Dec 2019 at 02:08, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
On 2019-Dec-10, Tomas Vondra wrote:

> On Tue, Dec 10, 2019 at 09:42:17AM +0900, Kyotaro Horiguchi wrote:
> > At Tue, 10 Dec 2019 00:44:09 +0100, Tomas Vondra <tomas.vondra@2ndquadrant.com> wrote in

> > I'm not sure how much xact_start for walsender is useful and we really
> > is not running a statement there.  Also autovac launcher starts
> > transaction without a valid statement timestamp perhaps for the same
> > reason.
>
> Maybe, but then maybe we should change it so that we don't report any
> timestamps for such processes.

Yeah, I think we should to that.

Agreed. Don't report a transaction start timestamp at all if we're not in a read/write txn in the walsender, which we should never be when using a historic snapshot.

It's not interesting or relevant.

Reporting the commit timestamp of the current or last-processed xact would likely just be fonfusing. I'd rather see that in pg_stat_replication if we're going to show it, that way we can label it usefully.

--
 Craig Ringer                   http://www.2ndQuadrant.com/
 2ndQuadrant - PostgreSQL Solutions for the Enterprise

pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: get_database_name() from background worker
Next
From: Amit Kapila
Date:
Subject: Re: [HACKERS] Block level parallel vacuum