At Fri, 13 Dec 2019 13:05:41 +0800, Craig Ringer <cr...@2ndquadrant.com> wrote in > On Wed, 11 Dec 2019 at 02:08, Alvaro Herrera <alvhe...@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.von...@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.
Sounds reasonable. By the way, the starting of this thread is a valid value in xact_timestample for a moment at the starting of logical replication. (I couln't see it unless I inserted a sleep() in IndentifySystem()). I'm not sure but AFAIS it is the only instance in walsendeer. Should we take the trouble to stop that? (I put -1 for it) regards. -- Kyotaro Horiguchi NTT Open Source Software Center
