Re: [HACKERS] Typo in backend/storage/ipc/standby.c

[Kyotaro HORIGUCHI]

At Wed, 12 Jul 2017 17:11:12 +0300, Heikki Linnakangas  wrote 
in 
> On 07/11/2017 10:34 AM, Kyotaro HORIGUCHI wrote:
> > 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.
> >
> Applied, thanks!

Thanks!

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Re: [HACKERS] Typo in backend/storage/ipc/standby.c

[Heikki Linnakangas]

On 07/11/2017 10:34 AM, Kyotaro HORIGUCHI wrote:

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.


Applied, thanks!

- Heikki



--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

[HACKERS] Typo in backend/storage/ipc/standby.c

[Kyotaro HORIGUCHI]

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 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

-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers