On Fri, Dec 27, 2019 at 04:46:18PM -0300, Alvaro Herrera wrote:
On 2019-Dec-13, Kyotaro Horiguchi wrote:
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.
This patch changes xact.c to avoid updating transaction start timestamps
for walsenders (maybe more commentary is desirable). I think logical
decoding is just a special form of walsender and thus it would also be
updated by this patch, unless I misunderstood what Tomas explained.
It's true walsender should not be doing any read-write transactions or
executing statements (well, maybe a decoding plugin could, but using
historic snapshot).
So I agree not leaving xact_start for walsender processes seems OK.
> Reporting the commit timestamp of the current or last-processed xact would
> likely just be confusing. 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.
Developers interested in this feature can submit a patch, as usual :-)
;-)
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
