Re: Recovery conflict resolution misses backends that import snapshots - Mailing list pgsql-hackers

From Scott Ray
Subject Re: Recovery conflict resolution misses backends that import snapshots
Date
Msg-id DOzJyHtChFYEWGD4fdobqc7ZMqKZub6NX0UgaDQaDeoUK_fQC9xQTX6FHpDTjSOzzfyMnWUNgqwsyPd5LWlsHXUn1Mz6xtHvFAXan1bLP-w=@scottray.io
Whole thread
In response to Re: Recovery conflict resolution misses backends that import snapshots  (Scott Ray <scott@scottray.io>)
List pgsql-hackers
On Saturday, September 12th, 2026 at 7:19 AM, Chee Wooson <chee.wooson@gmail.com> wrote:

> I do not see an invariant in v2 that
> prevents this chain from continuing, so I am concerned that the outer
> rescan loop does not have a strict termination guarantee. Am I missing
> such an invariant?

No such invariant exists.  I share Amit's concern about overengineering.

On Monday, July 27th, 2026 at 9:44 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:

> The other way to avoid looping here is to stop the chain from being
> extended: past the deadline, refuse new conflicting snapshot imports
> on the standby (aka "publish the intended horizon and reject
> conflicting imports"). I feel that is over engineering, instead, the
> current proposed solution looks reasonable to me

--
Scott Ray
Attachment

pgsql-hackers by date:

Previous
From: Scott Ray
Date:
Subject: Re: pg_xmin_horizon: a system view of everything pinning the xmin horizon
Next
From: Midhush Karthic
Date:
Subject: [PATCH] Add target-column context for assignment coercion errors