[HACKERS] Typo in backend/storage/ipc/standby.c - Mailing list pgsql-hackers

Hello.

I noticed that a comment above StandbyAcquireAccessExclusiveLock
in backend/storage/ipc/standby.c using wrong names of a variable
and a type.

The attached patch fixes it. The same mistake is found in older
versions back to 9.0.

fix_typo_of_standby_c_10_master.patch is for 10 and master and
fix_typo_of_standby_c_96_and_before.patch for 9.6 and before.

regards,

-- 
Kyotaro Horiguchi
NTT Open Source Software Center
*** a/src/backend/storage/ipc/standby.c
--- b/src/backend/storage/ipc/standby.c
***************
*** 587,596 **** StandbyLockTimeoutHandler(void)  * one transaction on one relation.  *  * We keep a single dynamically
expandiblelist of locks in local memory,
 
!  * RelationLockList, so we can keep track of the various entries made by  * the Startup process's virtual xid in the
sharedlock table.  *
 
!  * List elements use type xl_rel_lock, since the WAL record type exactly  * matches the information that we need to
keeptrack of.  *  * We use session locks rather than normal locks so we don't need
 
--- 587,596 ----  * one transaction on one relation.  *  * We keep a single dynamically expandible list of locks in
localmemory,
 
!  * RecoveryLockList, so we can keep track of the various entries made by  * the Startup process's virtual xid in the
sharedlock table.  *
 
!  * List elements use type xl_standby_lock, since the WAL record type exactly  * matches the information that we need
tokeep track of.  *  * We use session locks rather than normal locks so we don't need 
*** a/src/backend/storage/ipc/standby.c
--- b/src/backend/storage/ipc/standby.c
***************
*** 586,599 **** StandbyLockTimeoutHandler(void)  * one transaction on one relation.  *  * We keep a single dynamically
expandiblelist of locks in local memory,
 
!  * RelationLockList, so we can keep track of the various entries made by  * the Startup process's virtual xid in the
sharedlock table.  *  * We record the lock against the top-level xid, rather than individual  * subtransaction xids.
Thismeans AccessExclusiveLocks held by aborted  * subtransactions are not released as early as possible on standbys.
*
!  * List elements use type xl_rel_lock, since the WAL record type exactly  * matches the information that we need to
keeptrack of.  *  * We use session locks rather than normal locks so we don't need
 
--- 586,599 ----  * one transaction on one relation.  *  * We keep a single dynamically expandible list of locks in
localmemory,
 
!  * RecoveryLockList, so we can keep track of the various entries made by  * the Startup process's virtual xid in the
sharedlock table.  *  * We record the lock against the top-level xid, rather than individual  * subtransaction xids.
Thismeans AccessExclusiveLocks held by aborted  * subtransactions are not released as early as possible on standbys.
*
!  * List elements use type xl_standby_lock, since the WAL record type exactly  * matches the information that we need
tokeep track of.  *  * We use session locks rather than normal locks so we don't need