Re: xact_start for walsender & logical decoding not updated
| От | Craig Ringer |
|---|---|
| Тема | Re: xact_start for walsender & logical decoding not updated |
| Дата | |
| Msg-id | CAMsr+YHSdOev0ctrApJwa7T3Fjtfd5QVBMN84m4ax4oT6ctM8w@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: xact_start for walsender & logical decoding not updated (Alvaro Herrera <alvherre@2ndquadrant.com>) |
| Ответы |
Re: xact_start for walsender & logical decoding not updated
|
| Список | 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.
В списке pgsql-hackers по дате отправления: