Re: Recovery conflict resolution misses backends that import snapshots

From: Scott Ray <scott(at)scottray(dot)io>
To: Chee Wooson <chee(dot)wooson(at)gmail(dot)com>
Cc: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Zhijie Hou <houzj(dot)fnst(at)fujitsu(dot)com>, Hayato Kuroda <kuroda(dot)hayato(at)fujitsu(dot)com>, Bertrand Drouvot <bertranddrouvot(dot)pg(at)gmail(dot)com>
Subject: Re: Recovery conflict resolution misses backends that import snapshots
Date: 2026-09-27 21:12:01
Message-ID: DOzJyHtChFYEWGD4fdobqc7ZMqKZub6NX0UgaDQaDeoUK_fQC9xQTX6FHpDTjSOzzfyMnWUNgqwsyPd5LWlsHXUn1Mz6xtHvFAXan1bLP-w=@scottray.io
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Saturday, September 12th, 2026 at 7:19 AM, Chee Wooson <chee(dot)wooson(at)gmail(dot)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(dot)kapila16(at)gmail(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Midhush Karthic 2026-09-27 21:41:01 [PATCH] Add target-column context for assignment coercion errors
Previous Message Scott Ray 2026-09-27 21:06:48 Re: pg_xmin_horizon: a system view of everything pinning the xmin horizon