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

From Jeff Davis
Subject Question about StartLogicalReplication() error path
Date
Msg-id c5c861d576f2511732f8002c76245da587110b1c.camel@j-davis.com
Whole thread Raw
Responses Re: Question about StartLogicalReplication() error path
List pgsql-hackers
StartLogicalReplication() calls CreateDecodingContext(), which says:

  else if (start_lsn < slot->data.confirmed_flush)
  {
    /*
     * It might seem like we should error out in this case, but it's
     * pretty common for a client to acknowledge a LSN it doesn't
have to
     * do anything for, and thus didn't store persistently, because the
     * xlog records didn't result in anything relevant for logical
     * decoding. Clients have to be able to do that to support
synchronous
     * replication.
     */
     ...
     start_lsn = slot->data.confirmed_flush;
  }

But what about LSNs that are way in the past? Physical replication will
throw an error in that case (e.g. "requested WAL segment %s has already
been removed"), but StartLogicalReplication() ends up just starting
from confirmed_flush, which doesn't seem right.

I'm not sure I understand the comment overall. Why would the client
request something that it has already acknowledged, and why would the
server override that and just advance to the confirmed_lsn?

Regards,
    Jeff Davis





pgsql-hackers by date:

Previous
From: "osumi.takamichi@fujitsu.com"
Date:
Subject: timing sensitive failure of test_decoding RT that exists in PG9.6
Next
From: Jeff Davis
Date:
Subject: Re: Patch: Range Merge Join