Re: xact_start for walsender & logical decoding not updated

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: craig(at)2ndquadrant(dot)com
Cc: alvherre(at)2ndquadrant(dot)com, tomas(dot)vondra(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: xact_start for walsender & logical decoding not updated
Date: 2019-12-13 06:01:24
Message-ID: 20191213.150124.69303805839083319.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Fri, 13 Dec 2019 13:05:41 +0800, Craig Ringer <craig(at)2ndquadrant(dot)com> wrote in
> On Wed, 11 Dec 2019 at 02:08, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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(dot)vondra(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2019-12-13 06:26:11 Re: Errors "failed to construct the join relation" and "failed to build any 2-way joins"
Previous Message Surafel Temesgen 2019-12-13 05:49:20 Re: Conflict handling for COPY FROM