RE: Found issues related with logical replication and 2PC

Поиск
Список
Период
Сортировка
Искать
От
Hayato Kuroda (Fujitsu)
Тема
RE: Found issues related with logical replication and 2PC
Дата
Msg-id
TYAPR01MB5692FE540E4647F22B977599F5B92@TYAPR01MB5692.jpnprd01.prod.outlook.com
Ответ на
Список
Дерево обсуждения
Found issues related with logical replication and 2PC "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Re: Found issues related with logical replication and 2PC Amit Kapila <amit.kapila16@gmail.com>
RE: Found issues related with logical replication and 2PC "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Re: Found issues related with logical replication and 2PC shveta malik <shveta.malik@gmail.com>
Re: Found issues related with logical replication and 2PC Amit Kapila <amit.kapila16@gmail.com>
Re: Found issues related with logical replication and 2PC Amit Kapila <amit.kapila16@gmail.com>
Re: Found issues related with logical replication and 2PC shveta malik <shveta.malik@gmail.com>
Re: Found issues related with logical replication and 2PC Amit Kapila <amit.kapila16@gmail.com>
Re: Found issues related with logical replication and 2PC shveta malik <shveta.malik@gmail.com>
RE: Found issues related with logical replication and 2PC "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Re: Found issues related with logical replication and 2PC Amit Kapila <amit.kapila16@gmail.com>
Re: Found issues related with logical replication and 2PC shveta malik <shveta.malik@gmail.com>
RE: Found issues related with logical replication and 2PC "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Re: Found issues related with logical replication and 2PC Amit Kapila <amit.kapila16@gmail.com>
Dear Amit, Shveta,

Thanks for discussing!

I reported the issue because 1) I feared the risk of data loss and 2) simply
because the coding looked incorrect. However, per discussion, I understood that
it wouldn't lead to loss, and adding a global variable was unacceptable in this
case. I modified the patch completely.

The attached patch avoids using the LastCommitLSN as the local_lsn while applying
PREPARE. get_flush_position() was not changed. Also, it contains changes that
have not been discussed yet:

- Set last_commit_end to InvaldXLogPtr in the PREPARE case.
  This causes the same result as when the stream option is not "parallel."
- XactLastCommitEnd was replaced even ROLLBACK PREPARED case.
  Since the COMMIT PREPARED record is flushed in RecordTransactionAbortPrepared(),
  there is no need to ensure the WAL must be sent.


Best regards,
Hayato Kuroda
FUJITSU LIMITED

В списке pgsql-hackers по дате отправления
От: shveta malik
Дата:
От: Amit Kapila
Дата:
FAQ