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
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) |