changes_amit_1.patch
application/octet-stream
Filename: changes_amit_1.patch
Type: application/octet-stream
Part: 0
Patch
Same data as JSON:
GET /api/v1/attachments/:id/patch
the parsed metadata as JSON — format, series position, per-file stats; never the diff bytes.
API reference →
Format: unified
| File | + | − |
|---|---|---|
| src/backend/replication/logical/applyparallelworker.c | 19 | 17 |
diff --git a/src/backend/replication/logical/applyparallelworker.c b/src/backend/replication/logical/applyparallelworker.c
index 7422521626..7a30828d44 100644
--- a/src/backend/replication/logical/applyparallelworker.c
+++ b/src/backend/replication/logical/applyparallelworker.c
@@ -138,10 +138,11 @@
* wait to send messages, and this wait doesn't appear in lmgr.
*
* To avoid this wait, we use a non-blocking write and wait with a timeout. If
- * 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 enum TransApplyAction.
+ * the timeout is exceeded, the LA will serialize all the pending messages 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 as in the previous case
+ * which will detect deadlock if any. See pa_send_data() and
+ * enum TransApplyAction.
*
* 4) Lock types
*
@@ -575,11 +576,13 @@ pa_free_worker(ParallelApplyWorkerInfo *winfo)
/*
* Stop the worker if there are enough workers in the pool.
*
- * XXX The worker is also stopped if the leader apply worker needed to
+ * XXX Additionally, we also stop the worker if the leader apply worker
* serialize part of the transaction data due to a send timeout. This is
- * because the message could be partially written to the queue but there is
+ * because the message could be partially written to the queue and there is
* no way to clean the queue other than resending the message until it
- * succeeds. Directly stopping the worker avoids needing this complexity.
+ * succeeds. Instead of trying to send the data which anyway would have
+ * been serialized and then letting the parallel apply worker deal with the
+ * spurious message, we stop the worker.
*/
if (winfo->serialize_changes ||
list_length(ParallelApplyWorkerPool) >
@@ -652,7 +655,7 @@ pa_detach_all_error_mq(void)
}
/*
- * Check if the parallel apply worker is pending due to spooled messages.
+ * Check if there are any pending spooled messages.
*/
static bool
pa_has_spooled_message_pending()
@@ -665,8 +668,8 @@ pa_has_spooled_message_pending()
}
/*
- * Replay the spooled messages in the parallel apply worker if the leader apply
- * worker has finished serializing changes to the file.
+ * Replay the spooled messages once the leader apply worker has finished
+ * serializing changes to the file.
*/
static void
pa_spooled_messages(void)
@@ -699,8 +702,8 @@ pa_spooled_messages(void)
* We cannot read the file immediately after the leader has serialized all
* changes to the file because there may still be messages in the memory
* queue. We will apply all spooled messages the next time we call this
- * function, which should ensure that there are no messages left in the
- * memory queue.
+ * function and that will ensure there are no messages left in the memory
+ * queue.
*/
else if (fileset_state == FS_SERIALIZE_DONE)
{
@@ -811,7 +814,7 @@ LogicalParallelApplyLoop(shm_mq_handle *mqh)
}
else if (shmq_res == SHM_MQ_WOULD_BLOCK)
{
- /* Check if changes have been serialized to a file. */
+ /* Replay the changes from the file, if any. */
if (pa_has_spooled_message_pending())
{
pa_spooled_messages();
@@ -1207,8 +1210,7 @@ pa_send_data(ParallelApplyWorkerInfo *winfo, Size nbytes, const void *data)
* Switch to PARTIAL_SERIALIZE mode for the current transaction -- this means
* that the current data and any subsequent data for this transaction will be
* serialized to a file. This is done to prevent possible deadlocks with
- * another parallel apply worker (refer to the comments atop
- * applyparallelworker.c for details).
+ * another parallel apply worker (refer to the comments atop this file).
*/
void
pa_switch_to_partial_serialize(ParallelApplyWorkerInfo *winfo,
@@ -1217,7 +1219,7 @@ pa_switch_to_partial_serialize(ParallelApplyWorkerInfo *winfo,
/*
* 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 start to serialize data to file instead.
+ * and start serializing data to the file instead.
*/
winfo->serialize_changes = true;
@@ -1488,7 +1490,7 @@ pa_stream_abort(LogicalRepStreamAbortData *abort_data)
}
/*
- * Set the fileset state for the given parallel apply worker. The fileset
+ * Set the fileset state for a particular parallel apply worker. The fileset
* will be set once the leader worker serialized all changes to the file
* so that it can be used by parallel apply worker.
*/