Re: Question about StartLogicalReplication() error path - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: Question about StartLogicalReplication() error path
Date
Msg-id 20022e5d31d1a38b6bbf1b4e4f03eb94507342b3.camel@j-davis.com
Whole thread Raw
In response to Re: Question about StartLogicalReplication() error path  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Question about StartLogicalReplication() error path
List 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





pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: recent failures on lorikeet
Next
From: Andrew Dunstan
Date:
Subject: Re: Race condition in recovery?