Re: xact_start for walsender & logical decoding not updated
Craig Ringer <craig@2ndquadrant.com>
From: Craig Ringer <craig@2ndquadrant.com>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Tomas Vondra <tomas.vondra@2ndquadrant.com>, Kyotaro Horiguchi <horikyota.ntt@gmail.com>,
PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2019-12-13T05:05:41Z
Lists: 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
Commits
-
Reimplement nullification of walsender timestamp
- f5d28710c707 13.0 landed
- da42b9f3ff43 10.12 landed
- af43581e8b29 11.7 landed
- 20c4df8c8d7c 12.2 landed
-
pg_stat_activity: show NULL stmt start time for walsenders
- 8de3b68faffc 10.12 landed
- fce9ba8192b4 12.2 landed
- b175bd59fa54 13.0 landed
- 896db774e5b0 11.7 landed