Hi,
On Tue, Mar 4, 2025 at 4:59 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
> > >
> > > Sure thing. I've just added '(..) In the extreme cases this can..' as
> > > it is pretty rare to hit it. Patch attached.
> >
> > When the clock moves forward or backward, couldn't it affect
> > not only the standby but also the primary? I’m wondering
> > because TimestampDifferenceExceeds() seems to be used
> > in several places in addition to hot standby feedback.
> >
>
> Right, it could impact other places as well, like background WAL flush
> being delayed. So, what should we do about this? Shall we leave this
> as is, make a general statement, find all cases and make a note about
> them in docs, do it for the important ones where the impact is more,
> or something else?
Given the occurrence of such conditions is almost close to 0, we could
just open a new separate doc thread/cfentry if somebody is concerned
and add some general statement that OS time should not jump too much
(in some installation section), that it should be slewed (gradually
adjusted) instead. If someone has time jumping on his box back and
forth and something stops working , I still think he has bigger issues
(e.g. now() reflecting wrong data). I would stay vague as much as
possible, because every installation seems to use something different
(hypervisor, kernel modules, ntpd vs ntpd -x and so on).
The problem here was that standby was deteriorating primary (so you
couldn't see easily on primary what could be causing this), so IMHO
patch is fine as it stands, it just adds another not so known reason
to the pool of knowledge why backend_xmin might stop propagating.
-J.
