Re: BUG #18897: Logical replication conflict after using pg_createsubscriber under heavy load

Zane Duffield <duffieldzane@gmail.com>

From: Zane Duffield <duffieldzane@gmail.com>

To: vignesh C <vignesh21@gmail.com>

Cc: Shlok Kyal <shlok.kyal.oss@gmail.com>, Euler Taveira <euler@eulerto.com>, pgsql-bugs@lists.postgresql.org

Date: 2025-04-29T00:09:40Z

Lists: pgsql-bugs

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Fix duplicate transaction replay during pg_createsubscriber.
- e1c3654839e4 19 (unreleased) landed
- 33f74b806ce3 18.0 landed
- 967309116f0d 17.6 landed
pg_createsubscriber: Fix an unpredictable recovery wait time.
- 03b08c8f5f3e 18.0 cited

On Mon, Apr 28, 2025 at 2:58 PM vignesh C <vignesh21@gmail.com> wrote:

> As an alternative, we could set recovery_target_inclusive to false in
> the setup_recovery function. This way, recovery would stop just before
> the recovery target, allowing the publisher to start replicating
> exactly from the consistent point.
> Thoughts?

This sounds to me like a simpler and more correct solution.

Thanks,
Zane