postgres.git / summary / log / commit / refs

commit    fb646cbd5a9e83441744160f89d6ba01f2f0bf8b
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Tue Jun 07 19:34:30 2022 +0000
First released in: 15.0, 10.22, 11.17, 12.12, 13.8, 14.4

    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


 src/backend/replication/logical/launcher.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/backend/replication/logical/launcher.c b/src/backend/replication/logical/launcher.c
index b725c9213e3..4ea37e7ed95 100644
--- a/src/backend/replication/logical/launcher.c
+++ b/src/backend/replication/logical/launcher.c
@@ -1147,7 +1147,7 @@ pg_stat_get_subscription(PG_FUNCTION_ARGS)
 	/* Make sure we get consistent view of the workers. */
 	LWLockAcquire(LogicalRepWorkerLock, LW_SHARED);
 
-	for (i = 0; i <= max_logical_replication_workers; i++)
+	for (i = 0; i < max_logical_replication_workers; i++)
 	{
 		/* for each row */
 		Datum		values[PG_STAT_GET_SUBSCRIPTION_COLS];


[parent: 89254606b61e]