RE: Add tests for concurrent DML retry paths in logical replication apply
Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com>
From: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
To: 'Bharath Rupireddy' <bharath.rupireddyforpostgres@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-28T07:47:54Z
Lists: pgsql-hackers
Dear Bharath, > While reading the logical replication apply code in execReplication.c, I noticed > that the retry paths in RelationFindReplTupleByIndex and RelationFindReplTupleSeq > for concurrent updates and deletes have no test coverage [1]. Specifically, > when the same tuple is being updated/deleted on the publisher and subscriber at > the same time, the dirty snapshot finds the tuple being modified by another > transaction, the apply worker waits and retries the index/sequential scan. Good catch. > The attached patch adds an injection point before table_tuple_lock and a TAP test > exercising these retry paths, hitting both TM_Updated and TM_Deleted. I read the code briefly. Here are questions: 1. The test looks like to add the test for retry acquiring the lock. But there is another retry path, which waits till xwait finishes. Do you have a reason to skip testing? 2. Is it OK to use the same injection point name twice? I cannot find the existing case. Best regards, Hayato Kuroda FUJITSU LIMITED