From: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
---|---|
To: | 'Amit Kapila' <amit(dot)kapila16(at)gmail(dot)com>, shveta malik <shveta(dot)malik(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | RE: Found issues related with logical replication and 2PC |
Date: | 2024-08-08 09:07:00 |
Message-ID: | TYAPR01MB5692FE540E4647F22B977599F5B92@TYAPR01MB5692.jpnprd01.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
v2-0001-Not-to-store-the-flush-position-of-the-PREPARE-re.patch | application/octet-stream | 2.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2024-08-08 09:27:20 | Re: Logical Replication of sequences |
Previous Message | shveta malik | 2024-08-08 08:54:46 | Re: Found issues related with logical replication and 2PC |