Re: Question about StartLogicalReplication() error path

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <rhaas(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>
Subject: Re: Question about StartLogicalReplication() error path
Date: 2021-06-14 16:50:32
Message-ID: 20022e5d31d1a38b6bbf1b4e4f03eb94507342b3.camel@j-davis.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sat, 2021-06-12 at 16:17 +0530, Amit Kapila wrote:
> AFAIU, currently, in such a case, the subscriber (client) won't
> advance the flush location (confirmed_flush_lsn). So, we won't lose
> any data.

I think you are talking about the official Logical Replication
specifically, rather than an arbitrary client that's using the logical
replication protocol based on the protocol docs.

It seems that there's not much agreement in a behavior change here. I
suggest one or more of the following:

1. change the logical rep protocol docs to match the current behavior
a. also briefly explain in the docs why it's different from
physical replication (which does always start at the provided LSN as
far as I can tell)

2. Change the comment to add something like "Starting at a different
LSN than requested might not catch certain kinds of client errors.
Clients should be careful to check confirmed_flush_lsn if starting at
the requested LSN is required."

3. upgrade DEBUG1 message to a WARNING

Can I get agreement on any of the above suggestions?

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrew Dunstan 2021-06-14 16:56:46 Re: Race condition in recovery?
Previous Message Bruce Momjian 2021-06-14 16:49:19 Re: array_cat anycompatible change is breaking xversion upgrade tests (v14 release notes)