public inbox for [email protected]
help / color / mirror / Atom feedFrom: Amit Kapila <[email protected]>
To: [email protected] <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: [email protected] <[email protected]>
Cc: Peter Smith <[email protected]>
Cc: Dilip Kumar <[email protected]>
Cc: [email protected] <[email protected]>
Cc: PostgreSQL Hackers <[email protected]>
Subject: Re: Perform streaming logical transactions by background workers and parallel apply
Date: Wed, 30 Nov 2022 16:23:50 +0530
Message-ID: <CAA4eK1LGKYUDFZ_jFPrU497wQf2HNvt5a+tCTpqSeWSG6kfpSA@mail.gmail.com> (raw)
In-Reply-To: <OS0PR01MB5716B802A1733548A99761AE94129@OS0PR01MB5716.jpnprd01.prod.outlook.com>
References: <CAA4eK1JQTDXTfvJ5d+L0ggG4+doyd0Xji=e0OJsb=qcn_jWALA@mail.gmail.com>
<OS0PR01MB5716D6D2765E54DC739F288E940A9@OS0PR01MB5716.jpnprd01.prod.outlook.com>
<OS0PR01MB5716997A7115715F9E4EE520940D9@OS0PR01MB5716.jpnprd01.prod.outlook.com>
<CAA4eK1JEFVZcymteMYXhYghiX7Lb=MKuEsfxgD1VfaRrLCHyzg@mail.gmail.com>
<OS0PR01MB571663F65904D00895AD159994109@OS0PR01MB5716.jpnprd01.prod.outlook.com>
<CAA4eK1JuRPUY2Dx=vUToRksTmW0ptqMVT3K32g0368f_ZCk-zg@mail.gmail.com>
<OS0PR01MB5716B802A1733548A99761AE94129@OS0PR01MB5716.jpnprd01.prod.outlook.com>
On Tue, Nov 29, 2022 at 10:18 AM [email protected]
<[email protected]> wrote:
>
> Attach the new version patch which addressed all comments.
>
Some comments on v53-0002*
========================
1. I think testing the scenario where the shm_mq buffer is full
between the leader and parallel apply worker would require a large
amount of data and then also there is no guarantee. How about having a
developer GUC [1] force_apply_serialize which allows us to serialize
the changes and only after commit the parallel apply worker would be
allowed to apply it?
I am not sure if we can reliably test the serialization of partial
changes (like some changes have been already sent to parallel apply
worker and then serialization happens) but at least we can test the
serialization of complete xacts and their execution via parallel apply
worker.
2.
+ /*
+ * The stream lock is released when processing changes in a
+ * streaming block, so the leader needs to acquire the lock here
+ * before entering PARTIAL_SERIALIZE mode to ensure that the
+ * parallel apply worker will wait for the leader to release the
+ * stream lock.
+ */
+ if (in_streamed_transaction &&
+ action != LOGICAL_REP_MSG_STREAM_STOP)
+ {
+ pa_lock_stream(winfo->shared->xid, AccessExclusiveLock);
This comment is not completely correct because we can even acquire the
lock for the very streaming chunk. This check will work but doesn't
appear future-proof or at least not very easy to understand though I
don't have a better suggestion at this stage. Can we think of a better
check here?
3. I have modified a few comments in v53-0002* patch and the
incremental patch for the same is attached.
[1] - https://www.postgresql.org/docs/devel/runtime-config-developer.html
--
With Regards,
Amit Kapila.
Attachments:
[application/octet-stream] changes_amit_v53_0002.patch (3.2K, ../CAA4eK1LGKYUDFZ_jFPrU497wQf2HNvt5a+tCTpqSeWSG6kfpSA@mail.gmail.com/2-changes_amit_v53_0002.patch)
download | inline diff:
diff --git a/src/backend/replication/logical/applyparallelworker.c b/src/backend/replication/logical/applyparallelworker.c
index 3acf9d5fb9..1fc62cdba2 100644
--- a/src/backend/replication/logical/applyparallelworker.c
+++ b/src/backend/replication/logical/applyparallelworker.c
@@ -74,10 +74,10 @@
* messages, and this wait doesn't appear in lmgr.
*
* To resolve this issue, we use non-blocking write and wait with a timeout. If
- * timeout is exceeded, the LA will serialize the message to a file and
+ * the timeout is exceeded, the LA will serialize the message to a file and
* indicate PA-2 that it needs to read that file for the remaining messages.
* Then LA will start waiting for commit which will detect deadlock if any.
- * (See pa_send_data() and typedef enum TransApplyAction)
+ * (See pa_send_data() and enum TransApplyAction)
*
* 4) Lock type
*
@@ -1147,9 +1147,10 @@ pa_send_data(ParallelApplyWorkerInfo *winfo, Size nbytes, const void *data)
LogicalRepMsgType action;
/*
- * The parallel apply worker might be stuck for some reason, so
- * stop sending data directly to it and start to serialize data to
- * files instead.
+ * The parallel apply worker could be stuck for some reason (say
+ * waiting on some lock by other backend), so stop trying to send
+ * data directly to it and instead start to serialize data to
+ * file instead.
*/
winfo->serialize_changes = true;
diff --git a/src/backend/replication/logical/worker.c b/src/backend/replication/logical/worker.c
index b5fb74572e..c51d92b67f 100644
--- a/src/backend/replication/logical/worker.c
+++ b/src/backend/replication/logical/worker.c
@@ -1331,7 +1331,6 @@ apply_handle_stream_prepare(StringInfo s)
*/
pa_unlock_stream(winfo->shared->xid, AccessExclusiveLock);
- /* Send STREAM PREPARE message to the parallel apply worker. */
if (apply_action == TRANS_LEADER_SEND_TO_PARALLEL)
pa_send_data(winfo, s->len, s->data);
else
@@ -1339,6 +1338,10 @@ apply_handle_stream_prepare(StringInfo s)
LOGICAL_REP_MSG_STREAM_PREPARE,
&original_msg);
+ /*
+ * It is possible that while sending this change to parallel apply
+ * worker we need to switch to serialize mode.
+ */
if (winfo->serialize_changes)
pa_set_fileset_state(winfo->shared, FS_READY);
@@ -1840,6 +1843,10 @@ apply_handle_stream_abort(StringInfo s)
if (toplevel_xact)
{
+ /*
+ * It is possible that while sending this change to parallel apply
+ * worker we need to switch to serialize mode.
+ */
if (winfo->serialize_changes)
pa_set_fileset_state(winfo->shared,
FS_READY);
@@ -2062,13 +2069,16 @@ apply_handle_stream_commit(StringInfo s)
*/
pa_unlock_stream(xid, AccessExclusiveLock);
- /* Send STREAM COMMIT message to the parallel apply worker. */
if (apply_action == TRANS_LEADER_SEND_TO_PARALLEL)
pa_send_data(winfo, s->len, s->data);
else
stream_open_and_write_change(xid, LOGICAL_REP_MSG_STREAM_COMMIT,
&original_msg);
+ /*
+ * It is possible that while sending this change to parallel apply
+ * worker we need to switch to serialize mode.
+ */
if (winfo->serialize_changes)
pa_set_fileset_state(winfo->shared,
FS_READY);
view thread (616+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Perform streaming logical transactions by background workers and parallel apply
In-Reply-To: <CAA4eK1LGKYUDFZ_jFPrU497wQf2HNvt5a+tCTpqSeWSG6kfpSA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox