From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, craig(at)2ndquadrant(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: xact_start for walsender & logical decoding not updated |
Date: | 2020-01-07 23:52:34 |
Message-ID: | 20200107235234.GA21729@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2020-Jan-07, Tom Lane wrote:
> I wrote:
> > The buildfarm seems less than happy with this.
>
> ... and, having now looked at the patch, I'm not surprised.
> Breaking stmtStartTimestamp, which is what you did, seems like
> an awfully side-effect-filled route to the goal. If you want
> to prevent monitoring from showing this, why didn't you just
> prevent monitoring from showing it? That is, I'd have expected
> some am_walsender logic in or near pgstat.c, not here.
That seems a pretty simple patch; attached (untested). However, my
patch seemed a pretty decent way to achieve the goal, and I don't
understand why it causes the failure, or indeed why we care about
stmtStartTimestamp at all. I'll look into this again tomorrow.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
walsender-ts.patch | text/x-diff | 1.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Thomas Munro | 2020-01-08 00:13:30 | Re: Avoiding hash join batch explosions with extreme skew and weird stats |
Previous Message | Robert Haas | 2020-01-07 23:49:01 | Re: Removing pg_pltemplate and creating "trustable" extensions |