[HACKERS] Typo in backend/storage/ipc/standby.c
От | Kyotaro HORIGUCHI |
---|---|
Тема | [HACKERS] Typo in backend/storage/ipc/standby.c |
Дата | |
Msg-id | 20170711.163441.241981736.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответы |
Re: [HACKERS] Typo in backend/storage/ipc/standby.c
(Heikki Linnakangas <hlinnaka@iki.fi>)
|
Список | 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
В списке pgsql-hackers по дате отправления: