Hi Euler!, On Thu, Dec 5, 2024 at 4:07 PM Euler Taveira <eu...@eulerto.com> wrote:
> On Thu, Dec 5, 2024, at 6:43 AM, Jakub Wartak wrote: > > One of our customers ran into a very odd case, where hot standby feedback > backend_xmin propagation stopped working due to major (hours/days) clock > time shifts on hypervisor-managed VMs. This happens (and is fully > reproducible) e.g. in scenarios where standby connects and its own VM is > having time from the future (relative to primary) and then that time goes > back to "normal". In such situation "sends hot_standby_feedback xmin" > timestamp messages are stopped being transferred, e.g.: > > > Is it worth a WARNING message if there is a "huge" time difference > between the servers? We already have the reply time in the message so > it is a matter of defining the "huge" interval plus a roundtrip. We also > need to avoid spamming the log. > I'm trying to stay consistent with what the recovery_min_apply_delay did (there is a warning in the docs, but there's no warning in code) and I just wanted the to have pointer in the documentation that if someone is using hot_standby_feedback then he would be at least warned before. Given it is very rare I don't think we need additional code (+ what Andres has noted ). > Your patch looks good to me. Should it be converted into a > <note>...</note>? (See synchronous_standby_names [1] for an example.) > Fine for me, but we would have to also convert the recovery_min_apply_delay to do the same, right? -J.
