Re: Tracking last scan time

Поиск
Список
Период
Сортировка
От Kyotaro Horiguchi
Тема Re: Tracking last scan time
Дата
Msg-id 20220907.175822.878410517170547060.horikyota.ntt@gmail.com
обсуждение исходный текст
Ответ на Re: Tracking last scan time  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: Different compression methods for FPI
Следующее
От: Christoph Berg
Дата:
Сообщение: PostGIS and json_categorize_type (Re: pgsql: Revert SQL/JSON features)