Re: xact_start for walsender & logical decoding not updated
От | Tomas Vondra |
---|---|
Тема | Re: xact_start for walsender & logical decoding not updated |
Дата | |
Msg-id | 20191210115903.x5j3rfxtr3notsut@development обсуждение исходный текст |
Ответ на | Re: xact_start for walsender & logical decoding not updated (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: xact_start for walsender & logical decoding not updated
|
Список | pgsql-hackers |
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 >> Hi, >> >> I think there's a minor bug in pg_stat_activity tracking of walsender >> processes. The issue is that xact_start is only updated at the very >> beginning when the walsender starts (so it's almost exactly equal to >> backend_start) and then just flips between NULL and that value. >> >> Reproducing this is trivial - just create a publication/subscription >> with the built-in logical replication, and run arbitrary workload. >> You'll see that the xact_start value never changes. >> >> I think the right fix is calling SetCurrentStatementStartTimestamp() >> right before StartTransactionCommand() in ReorderBufferCommit, per the >> attached patch. > >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. >However, if we want to show something meaningful there, I think >commit_time might be more informative there. If we use >GetCurrentTimestamp(), StartTransaction() already has the same feature >for autonomous transactions. I suppose we should do them a unified >way. > I don't think so. We have this information from the apply side, and this is really about the *new* transaction started in reorderbuffer. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: