On Fri, Jun 11, 2021 at 11:52 AM Jeff Davis <pg...@j-davis.com> wrote: > > On Fri, 2021-06-11 at 10:13 +0530, Amit Kapila wrote: > > I think because there is no need to process the WAL that has been > > confirmed by the client. Do you see any problems with this scheme? > > Several: > > * Replication setups are complex, and it can be easy to misconfigure > something or have a bug in some control code. An error is valuable to > detect the problem closer to the source. > > * There are plausible configurations where things could go badly wrong. > For instance, if you are storing the decoded data in another postgres > server with syncrhonous_commit=off, and acknowledging LSNs before they > are durable. A crash of the destination system would be consistent, but > it would be missing some data earlier than the confirmed_flush_lsn. The > client would then request the data starting at its stored lsn progress > value, but the server would skip ahead to the confirmed_flush_lsn; > silently missing data. >
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. -- With Regards, Amit Kapila.
