Re: Tracking last scan time - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Tracking last scan time
Date
Msg-id 20220907.175822.878410517170547060.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Tracking last scan time  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
At Tue, 6 Sep 2022 08:53:25 -0700, Andres Freund <andres@anarazel.de> wrote in 
> Hi,
> 
> On 2022-09-06 14:15:56 +0100, Dave Page wrote:
> > Vik and I looked at this a little, and found that we actually don't have
> > generally have GetCurrentTransactionStopTimestamp() at this point - a
> > simple 'select * from pg_class' will result in 9 passes of this code, none
> > of which have xactStopTimestamp != 0.
> 
> Huh, pgstat_report_stat() used GetCurrentTransactionStopTimestamp() has used
> for a long time. Wonder when that was broken. Looks like it's set only when a
> xid is assigned. We should fix this.

/*
 *    GetCurrentTransactionStopTimestamp
 *
 * We return current time if the transaction stop time hasn't been set
 * (which can happen if we decide we don't need to log an XLOG record).

So, that seems like intentional since 2007 (957d08c81f).  It seems to
me that the patch assumes that the only other use of the timstamp is
pgstats and it didn't let GetCurrentTransactionStopTimestamp() set the
variable for future use.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: Different compression methods for FPI
Next
From: Christoph Berg
Date:
Subject: PostGIS and json_categorize_type (Re: pgsql: Revert SQL/JSON features)