Question about StartLogicalReplication() error path

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Question about StartLogicalReplication() error path
Дата
Msg-id c5c861d576f2511732f8002c76245da587110b1c.camel@j-davis.com
обсуждение исходный текст
Ответы Re: Question about StartLogicalReplication() error path  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "osumi.takamichi@fujitsu.com"
Дата:
Сообщение: timing sensitive failure of test_decoding RT that exists in PG9.6
Следующее
От: Jeff Davis
Дата:
Сообщение: Re: Patch: Range Merge Join