Skip to content

Commit a361969

Browse files
committed
Fix off-by-one loop termination condition in pg_stat_get_subscription().
pg_stat_get_subscription scanned one more LogicalRepWorker array entry than is really allocated. In the worst case this could lead to SIGSEGV, if the LogicalRepCtx data structure is near the end of shared memory. That seems quite unlikely though (thanks to the ordering of calls in CreateSharedMemoryAndSemaphores) and we've heard no field reports of it. A more likely misbehavior is one row of garbage data in the function's result, but even that is not real likely because of the check that the pid field matches some live backend. Report and fix by Kuntal Ghosh. This bug is old, so back-patch to all supported branches. Discussion: https://postgr.es/m/CAGz5QCJykEDzW6jQK6Yz7Qh_PMtD=95de_7QoocbVR2Qy8hWZA@mail.gmail.com
1 parent 16d6800 commit a361969

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

src/backend/replication/logical/launcher.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1106,7 +1106,7 @@ pg_stat_get_subscription(PG_FUNCTION_ARGS)
11061106
/* Make sure we get consistent view of the workers. */
11071107
LWLockAcquire(LogicalRepWorkerLock, LW_SHARED);
11081108

1109-
for (i = 0; i <= max_logical_replication_workers; i++)
1109+
for (i = 0; i < max_logical_replication_workers; i++)
11101110
{
11111111
/* for each row */
11121112
Datum values[PG_STAT_GET_SUBSCRIPTION_COLS];

0 commit comments

Comments
 (0)