Typo in backend/storage/ipc/standby.c

*** 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 expandible list 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 shared lock table.
   *
!  * List elements use type xl_rel_lock, since the WAL record type exactly
   * matches the information that we need to keep track 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 local memory,
!  * RecoveryLockList, so we can keep track of the various entries made by
   * the Startup process's virtual xid in the shared lock table.
   *
!  * List elements use type xl_standby_lock, since the WAL record type exactly
   * matches the information that we need to keep 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 expandible list 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 shared lock table.
   *
   * We record the lock against the top-level xid, rather than individual
   * subtransaction xids. This means 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 keep track 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 local memory,
!  * RecoveryLockList, so we can keep track of the various entries made by
   * the Startup process's virtual xid in the shared lock table.
   *
   * We record the lock against the top-level xid, rather than individual
   * subtransaction xids. This means 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 to keep track of.
   *
   * We use session locks rather than normal locks so we don't need