ການປົດລັອກ Postgres Lock Manager. Bruce Momjian

Transcript of Bruce Momjian's 2020 talk "Unlocking the Postgres Lock Manager".

(ຫມາຍເຫດ: ຄໍາຖາມ SQL ທັງຫມົດຈາກສະໄລ້ສາມາດໄດ້ຮັບຈາກການເຊື່ອມຕໍ່ນີ້: http://momjian.us/main/writings/pgsql/locking.sql)

ສະບາຍດີ! ມັນເປັນການດີທີ່ຈະຢູ່ທີ່ນີ້ໃນລັດເຊຍອີກເທື່ອຫນຶ່ງ. ຂ້ອຍຂໍໂທດທີ່ຂ້ອຍບໍ່ສາມາດມາໃນປີທີ່ຜ່ານມາ, ແຕ່ປີນີ້ Ivan ແລະຂ້ອຍມີແຜນການໃຫຍ່. ຂ້ອຍຫວັງວ່າຈະຢູ່ທີ່ນີ້ເລື້ອຍໆ. ຂ້ອຍມັກມາລັດເຊຍ. ຂ້ອຍຈະໄປຢ້ຽມຢາມ Tyumen, Tver. ຂ້ອຍດີໃຈຫຼາຍທີ່ຂ້ອຍຈະໄດ້ໄປຢ້ຽມຢາມເມືອງເຫຼົ່ານີ້.

ຂ້ອຍຊື່ Bruce Momjian. ຂ້ອຍເຮັດວຽກຢູ່ EnterpriseDB ແລະໄດ້ເຮັດວຽກກັບ Postgres ຫຼາຍກວ່າ 23 ປີ. ຂ້ອຍອາໄສຢູ່ Philadelphia, USA. ຂ້ອຍເດີນທາງປະມານ 90 ມື້ຕໍ່ປີ. ແລະຂ້ອຍເຂົ້າຮ່ວມປະມານ 40 ກອງປະຊຸມ. ຂອງຂ້ອຍ ເວັບໄຊທ໌, ເຊິ່ງປະກອບດ້ວຍສະໄລ້ທີ່ຂ້າພະເຈົ້າຈະສະແດງໃຫ້ທ່ານເຫັນໃນປັດຈຸບັນ. ດັ່ງນັ້ນ, ຫຼັງຈາກກອງປະຊຸມທ່ານສາມາດດາວໂຫລດພວກມັນໄດ້ຈາກເວັບໄຊທ໌ສ່ວນຕົວຂອງຂ້ອຍ. ມັນຍັງປະກອບດ້ວຍປະມານ 30 ການນໍາສະເຫນີ. ຍັງມີວິດີໂອແລະຈໍານວນ blog ຈໍານວນຫລາຍ, ຫຼາຍກວ່າ 500. ນີ້ແມ່ນຊັບພະຍາກອນທີ່ຂ້ອນຂ້າງ. ແລະຖ້າຫາກວ່າທ່ານມີຄວາມສົນໃຈໃນອຸປະກອນການນີ້, ຫຼັງຈາກນັ້ນຂ້າພະເຈົ້າເຊື້ອເຊີນໃຫ້ທ່ານນໍາໃຊ້ມັນ.

ຂ້ອຍເຄີຍເປັນຄູສອນ, ສາດສະດາຈານກ່ອນທີ່ຂ້ອຍຈະເລີ່ມເຮັດວຽກກັບ Postgres. ແລະ​ຂ້າ​ພະ​ເຈົ້າ​ດີ​ໃຈ​ຫຼາຍ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ສາ​ມາດ​ບອກ​ທ່ານ​ໃນ​ສິ່ງ​ທີ່​ຂ້າ​ພະ​ເຈົ້າ​ກໍາ​ລັງ​ຈະ​ບອກ​ທ່ານ​. ນີ້ແມ່ນການນໍາສະເຫນີທີ່ຫນ້າສົນໃຈທີ່ສຸດຂອງຂ້ອຍ. ແລະການນໍາສະເຫນີນີ້ມີ 110 ສະໄລ້. ພວກເຮົາຈະເລີ່ມຕົ້ນສົນທະນາກັບສິ່ງທີ່ງ່າຍດາຍ, ແລະໃນທີ່ສຸດບົດລາຍງານຈະກາຍເປັນຄວາມສັບສົນຫຼາຍ, ແລະຈະກາຍເປັນສະລັບສັບຊ້ອນຫຼາຍ.

ນີ້ແມ່ນການສົນທະນາທີ່ບໍ່ພໍໃຈຫຼາຍ. ການຂັດຂວາງບໍ່ແມ່ນຫົວຂໍ້ທີ່ນິຍົມຫຼາຍທີ່ສຸດ. ພວກເຮົາຕ້ອງການໃຫ້ມັນຫາຍໄປບາງບ່ອນ. ມັນຄ້າຍຄືກັບການໄປຫາຫມໍປົວແຂ້ວ.

1. ການລັອກແມ່ນບັນຫາສໍາລັບຫຼາຍໆຄົນທີ່ເຮັດວຽກຢູ່ໃນຖານຂໍ້ມູນແລະມີຫຼາຍຂະບວນການເຮັດວຽກໃນເວລາດຽວກັນ. ພວກເຂົາຕ້ອງການສະກັດ. ນັ້ນແມ່ນ, ມື້ນີ້ຂ້ອຍຈະໃຫ້ຄວາມຮູ້ພື້ນຖານກ່ຽວກັບການຂັດຂວາງ.
2. ID ທຸລະກຳ. ນີ້ແມ່ນສ່ວນຫນຶ່ງທີ່ຫນ້າເບື່ອຫຼາຍຂອງການນໍາສະເຫນີ, ແຕ່ພວກເຂົາຈໍາເປັນຕ້ອງເຂົ້າໃຈ.
3. ຕໍ່ໄປພວກເຮົາຈະສົນທະນາກ່ຽວກັບປະເພດຂອງການສະກັດ. ນີ້ແມ່ນພາກສ່ວນກົນຈັກທີ່ຂ້ອນຂ້າງ.
4. ແລະຂ້າງລຸ່ມນີ້ພວກເຮົາຈະໃຫ້ຕົວຢ່າງບາງຢ່າງຂອງການຂັດຂວາງ. ແລະມັນຈະຂ້ອນຂ້າງຍາກທີ່ຈະເຂົ້າໃຈ.

ໃຫ້ເວົ້າກ່ຽວກັບການຂັດຂວາງ.

ຄໍາສັບຂອງພວກເຮົາແມ່ນຂ້ອນຂ້າງສັບສົນ. ມີ​ຈັກ​ຄົນ​ໃນ​ພວກ​ເຈົ້າ​ຮູ້​ວ່າ​ເສັ້ນ​ທາງ​ນີ້​ມາ​ຈາກ​ໃສ? ສອງຄົນ. ນີ້ແມ່ນມາຈາກເກມທີ່ມີຊື່ວ່າ Colossal Cave Adventure. ມັນເປັນເກມຄອມພິວເຕີທີ່ອີງໃສ່ຂໍ້ຄວາມໃນ 80s, ຂ້າພະເຈົ້າຄິດວ່າ. ຢູ່ທີ່ນັ້ນ, ເຈົ້າຕ້ອງເຂົ້າໄປໃນຖ້ໍາ, ເຂົ້າໄປໃນ labyrinth, ແລະຂໍ້ຄວາມມີການປ່ຽນແປງ, ແຕ່ເນື້ອໃນແມ່ນປະມານດຽວກັນທຸກໆຄັ້ງ. ນັ້ນແມ່ນວິທີທີ່ຂ້ອຍຈື່ເກມນີ້.

ແລະໃນທີ່ນີ້ພວກເຮົາເຫັນຊື່ຂອງ locks ທີ່ມາຫາພວກເຮົາຈາກ Oracle. ພວກເຮົາໃຊ້ພວກມັນ.

ນີ້ພວກເຮົາເຫັນຂໍ້ກໍານົດທີ່ເຮັດໃຫ້ຂ້ອຍສັບສົນ. ຕົວຢ່າງ, SHARE UPDATE ECXLUSIVE. ຕໍ່ໄປ SHARE RAW ECXLUSIVE. ດ້ວຍຄວາມຊື່ສັດ, ຊື່ເຫຼົ່ານີ້ບໍ່ຊັດເຈນຫຼາຍ. ພວກເຮົາຈະພະຍາຍາມພິຈາລະນາໃຫ້ເຂົາເຈົ້າໃນລາຍລະອຽດເພີ່ມເຕີມ. ບາງຄົນມີຄໍາວ່າ "ແບ່ງປັນ", ຊຶ່ງຫມາຍຄວາມວ່າຈະແຍກ. ບາງອັນມີຄຳວ່າ "ສະເພາະ". ບາງອັນມີທັງສອງຄຳນີ້. ຂ້ອຍຕ້ອງການເລີ່ມຕົ້ນດ້ວຍວິທີການລັອກເຫຼົ່ານີ້ເຮັດວຽກ.

ແລະຄໍາວ່າ "ການເຂົ້າເຖິງ" ຍັງມີຄວາມສໍາຄັນຫຼາຍ. ແລະຄໍາວ່າ "ແຖວ" ແມ່ນສາຍ. ນັ້ນແມ່ນ, ການແຈກຢາຍການເຂົ້າເຖິງ, ການແຈກຢາຍແຖວ.

ບັນຫາອີກອັນຫນຶ່ງທີ່ຕ້ອງໄດ້ຮັບການເຂົ້າໃຈໃນ Postgres, ແຕ່ຫນ້າເສຍດາຍທີ່ຂ້ອຍຈະບໍ່ສາມາດກວມເອົາໃນການສົນທະນາຂອງຂ້ອຍ, ແມ່ນ MVCC. ຂ້ອຍມີການນໍາສະເຫນີແຍກຕ່າງຫາກກ່ຽວກັບຫົວຂໍ້ນີ້ຢູ່ໃນເວັບໄຊທ໌ຂອງຂ້ອຍ. ແລະຖ້າທ່ານຄິດວ່າການນໍາສະເຫນີນີ້ແມ່ນຍາກ, MVCC ອາດຈະເປັນການຍາກທີ່ສຸດຂອງຂ້ອຍ. ແລະຖ້າຫາກວ່າທ່ານມີຄວາມສົນໃຈ, ທ່ານສາມາດເບິ່ງມັນຢູ່ໃນເວັບໄຊທ໌. ທ່ານສາມາດເບິ່ງວິດີໂອໄດ້.

ສິ່ງອື່ນທີ່ພວກເຮົາຕ້ອງເຂົ້າໃຈແມ່ນ ID ການເຮັດທຸລະກໍາ. ທຸລະກໍາຫຼາຍຢ່າງບໍ່ສາມາດເຮັດວຽກໄດ້ໂດຍບໍ່ມີຕົວລະບຸທີ່ເປັນເອກະລັກ. ແລະໃນທີ່ນີ້ພວກເຮົາມີຄໍາອະທິບາຍວ່າທຸລະກໍາແມ່ນຫຍັງ. Postgres ມີສອງລະບົບຕົວເລກການເຮັດທຸລະກໍາ. ຂ້ອຍຮູ້ວ່ານີ້ບໍ່ແມ່ນການແກ້ໄຂທີ່ສວຍງາມຫຼາຍ.

ຍັງຈື່ໄວ້ວ່າ slides ຈະຂ້ອນຂ້າງຍາກທີ່ຈະເຂົ້າໃຈ, ດັ່ງນັ້ນສິ່ງທີ່ເນັ້ນໃສ່ສີແດງແມ່ນສິ່ງທີ່ທ່ານຈໍາເປັນຕ້ອງເອົາໃຈໃສ່.

http://momjian.us/main/writings/pgsql/locking.sql

ໃຫ້ເຮົາເບິ່ງ. ໝາຍເລກທຸລະກຳຖືກເນັ້ນເປັນສີແດງ. ຟັງຊັນ SELECT pg_back ແມ່ນສະແດງຢູ່ທີ່ນີ້. ມັນສົ່ງຄືນການເຮັດທຸລະກໍາຂອງຂ້ອຍແລະ ID ການເຮັດທຸລະກໍາ.

ສິ່ງຫນຶ່ງອີກ, ຖ້າທ່ານຕ້ອງການການນໍາສະເຫນີນີ້ແລະຕ້ອງການດໍາເນີນການໃນຖານຂໍ້ມູນຂອງທ່ານ, ທ່ານສາມາດໄປທີ່ລິ້ງນີ້ໃນສີບົວແລະດາວໂຫລດ SQL ສໍາລັບການນໍາສະເຫນີນີ້. ແລະທ່ານພຽງແຕ່ສາມາດດໍາເນີນການມັນຢູ່ໃນ PSQL ຂອງທ່ານແລະການນໍາສະເຫນີທັງຫມົດຈະຢູ່ໃນຫນ້າຈໍຂອງທ່ານທັນທີ. ມັນ​ຈະ​ບໍ່​ມີ​ດອກ​ໄມ້, ແຕ່​ຢ່າງ​ຫນ້ອຍ​ພວກ​ເຮົາ​ສາ​ມາດ​ເບິ່ງ​ມັນ.

ໃນກໍລະນີນີ້ພວກເຮົາເຫັນ ID ການເຮັດທຸລະກໍາ. ນີ້ແມ່ນຕົວເລກທີ່ພວກເຮົາໄດ້ມອບຫມາຍໃຫ້ນາງ. ແລະມີ ID ການເຮັດທຸລະກໍາອື່ນໃນ Postgres, ເຊິ່ງເອີ້ນວ່າ ID ການເຮັດທຸລະກໍາ virtual

ແລະພວກເຮົາຕ້ອງເຂົ້າໃຈເລື່ອງນີ້. ນີ້ແມ່ນສິ່ງສໍາຄັນຫຼາຍ, ຖ້າບໍ່ດັ່ງນັ້ນພວກເຮົາຈະບໍ່ສາມາດເຂົ້າໃຈການລັອກໃນ Postgres.

ID ທຸລະກຳສະເໝືອນແມ່ນ ID ທຸລະກຳທີ່ບໍ່ມີຄ່າຄົງທີ່. ຕົວຢ່າງ, ຖ້າຂ້ອຍດໍາເນີນການຄໍາສັ່ງ SELECT, ສ່ວນຫຼາຍຂ້ອຍຈະບໍ່ປ່ຽນຖານຂໍ້ມູນ, ຂ້ອຍຈະບໍ່ລັອກຫຍັງ. ດັ່ງນັ້ນເມື່ອພວກເຮົາດໍາເນີນການ SELECT ງ່າຍໆ, ພວກເຮົາບໍ່ໃຫ້ທຸລະກໍານັ້ນເປັນ ID ຄົງທີ່. ພວກເຮົາພຽງແຕ່ໃຫ້ ID virtual ຂອງນາງຢູ່ທີ່ນັ້ນ.

ແລະນີ້ປັບປຸງການປະຕິບັດ Postgres, ປັບປຸງຄວາມສາມາດໃນການເຮັດຄວາມສະອາດ, ດັ່ງນັ້ນ ID ການເຮັດທຸລະກໍາ virtual ປະກອບດ້ວຍສອງຕົວເລກ. ຕົວເລກທຳອິດກ່ອນເຄື່ອງໝາຍເລກແມ່ນ ID backend. ແລະເບື້ອງຂວາພວກເຮົາເຫັນພຽງແຕ່ເຄົາເຕີ.

ດັ່ງນັ້ນ, ຖ້າຂ້ອຍດໍາເນີນການຮ້ອງຂໍ, ມັນບອກວ່າ backend ID ແມ່ນ 2.

ແລະຖ້າຂ້ອຍດໍາເນີນການໄລຍະການເຮັດທຸລະກໍາດັ່ງກ່າວ, ຫຼັງຈາກນັ້ນພວກເຮົາເຫັນວ່າ counter ເພີ່ມຂຶ້ນທຸກຄັ້ງທີ່ຂ້ອຍດໍາເນີນການສອບຖາມ. ຕົວຢ່າງ, ເມື່ອຂ້ອຍດໍາເນີນການສອບຖາມ 2/10, 2/11, 2/12, ແລະອື່ນໆ.

ຈົ່ງຈື່ໄວ້ວ່າມີສອງຄໍລໍາຢູ່ທີ່ນີ້. ຢູ່ເບື້ອງຊ້າຍພວກເຮົາເຫັນ ID ການເຮັດທຸລະກໍາ virtual – 2/12. ແລະຢູ່ເບື້ອງຂວາພວກເຮົາມີ ID ການເຮັດທຸລະກໍາຖາວອນ. ແລະພາກສະຫນາມນີ້ແມ່ນຫວ່າງເປົ່າ. ແລະທຸລະກໍານີ້ບໍ່ໄດ້ດັດແປງຖານຂໍ້ມູນ. ສະນັ້ນຂ້ອຍບໍ່ໄດ້ໃຫ້ມັນ ID ການເຮັດທຸລະກໍາຖາວອນ.

ທັນທີທີ່ຂ້ອຍແລ່ນຄໍາສັ່ງການວິເຄາະ ((ANALYZE)), ຄໍາຖາມດຽວກັນເຮັດໃຫ້ຂ້ອຍມີ ID ການເຮັດທຸລະກໍາຖາວອນ. ເບິ່ງວິທີການນີ້ມີການປ່ຽນແປງສໍາລັບພວກເຮົາ. ຂ້ອຍບໍ່ມີບັດປະຈຳຕົວນີ້ມາກ່ອນ, ແຕ່ດຽວນີ້ຂ້ອຍມີມັນ.

ສະນັ້ນນີ້ແມ່ນການຮ້ອງຂໍອື່ນ, ການເຮັດທຸລະກໍາອື່ນ. ໝາຍເລກທຸລະກຳສະເໝືອນແມ່ນວັນທີ 2/13. ແລະຖ້າຂ້ອຍຂໍ ID ການເຮັດທຸລະກໍາທີ່ຍັງຄົງຄ້າງ, ຫຼັງຈາກນັ້ນເມື່ອຂ້ອຍດໍາເນີນການສອບຖາມ, ຂ້ອຍຈະໄດ້ຮັບມັນ.

ດັ່ງນັ້ນ, ອີກເທື່ອຫນຶ່ງ. ພວກເຮົາມີ ID ທຸລະກຳສະເໝືອນ ແລະ ID ທຸລະກຳທີ່ຄົງຄ້າງ. ພຽງແຕ່ເຂົ້າໃຈຈຸດນີ້ເພື່ອເຂົ້າໃຈພຶດຕິກໍາຂອງ Postgres.

ພວກເຮົາກ້າວໄປສູ່ພາກທີສາມ. ໃນທີ່ນີ້ພວກເຮົາຈະພຽງແຕ່ຍ່າງຜ່ານປະເພດຕ່າງໆຂອງ locks ໃນ Postgres. ມັນບໍ່ຫນ້າສົນໃຈຫຼາຍ. ພາກສຸດທ້າຍຈະມີຄວາມຫນ້າສົນໃຈຫຼາຍ. ແຕ່ພວກເຮົາຕ້ອງພິຈາລະນາສິ່ງພື້ນຖານ, ເພາະວ່າຖ້າບໍ່ດັ່ງນັ້ນພວກເຮົາຈະບໍ່ເຂົ້າໃຈສິ່ງທີ່ຈະເກີດຂຶ້ນຕໍ່ໄປ.

ພວກເຮົາຈະຜ່ານພາກນີ້, ພວກເຮົາຈະເບິ່ງແຕ່ລະປະເພດຂອງ lock. ແລະຂ້າພະເຈົ້າຈະສະແດງໃຫ້ທ່ານເຫັນຕົວຢ່າງຂອງວິທີການຕິດຕັ້ງ, ວິທີການເຮັດວຽກ, ຂ້າພະເຈົ້າຈະສະແດງໃຫ້ທ່ານເຫັນບາງຄໍາຖາມທີ່ທ່ານສາມາດນໍາໃຊ້ເພື່ອເບິ່ງວິທີການລັອກໃນ Postgres.

ເພື່ອສ້າງແບບສອບຖາມແລະເບິ່ງສິ່ງທີ່ເກີດຂຶ້ນໃນ Postgres, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ອອກຄໍາຖາມໃນມຸມເບິ່ງລະບົບ. ໃນກໍລະນີນີ້, pg_lock ຖືກເນັ້ນເປັນສີແດງ. Pg_lock ແມ່ນຕາຕະລາງລະບົບທີ່ບອກພວກເຮົາວ່າລັອກໃດທີ່ຖືກນໍາໃຊ້ໃນ Postgres.

ຢ່າງໃດກໍຕາມ, ມັນເປັນການຍາກຫຼາຍສໍາລັບຂ້າພະເຈົ້າທີ່ຈະສະແດງໃຫ້ທ່ານ pg_lock ດ້ວຍຕົວມັນເອງເນື່ອງຈາກວ່າມັນຂ້ອນຂ້າງສັບສົນ. ດັ່ງນັ້ນຂ້າພະເຈົ້າໄດ້ສ້າງມຸມເບິ່ງທີ່ສະແດງໃຫ້ເຫັນ pg_locks. ແລະມັນຍັງເຮັດວຽກບາງຢ່າງສໍາລັບຂ້ອຍທີ່ຊ່ວຍໃຫ້ຂ້ອຍເຂົ້າໃຈດີຂຶ້ນ. ນັ້ນແມ່ນ, ມັນຍົກເວັ້ນການລັອກຂອງຂ້ອຍ, ເຊດຊັນຂອງຂ້ອຍເອງ, ແລະອື່ນໆ. ມັນເປັນພຽງແຕ່ SQL ມາດຕະຖານແລະມັນຊ່ວຍໃຫ້ທ່ານສາມາດສະແດງໃຫ້ທ່ານເຫັນສິ່ງທີ່ກໍາລັງເກີດຂຶ້ນ.

ບັນຫາອີກອັນຫນຶ່ງແມ່ນວ່າມຸມເບິ່ງນີ້ແມ່ນກວ້າງຫຼາຍ, ດັ່ງນັ້ນຂ້ອຍຕ້ອງສ້າງອັນທີສອງ - lockview2 .

ແລະມັນສະແດງໃຫ້ຂ້ອຍເຫັນຖັນເພີ່ມເຕີມຈາກຕາຕະລາງ. ແລະອີກອັນຫນຶ່ງທີ່ສະແດງໃຫ້ຂ້ອຍເຫັນສ່ວນທີ່ເຫຼືອຂອງຄໍລໍາ. ນີ້ແມ່ນຂ້ອນຂ້າງສັບສົນ, ສະນັ້ນຂ້າພະເຈົ້າໄດ້ພະຍາຍາມນໍາສະເຫນີມັນງ່າຍດາຍເທົ່າທີ່ເປັນໄປໄດ້.

ດັ່ງນັ້ນພວກເຮົາໄດ້ສ້າງຕາຕະລາງທີ່ເອີ້ນວ່າ Lockdemo. ແລະພວກເຮົາໄດ້ສ້າງເສັ້ນຫນຶ່ງຢູ່ທີ່ນັ້ນ. ນີ້ແມ່ນຕາຕະລາງຕົວຢ່າງຂອງພວກເຮົາ. ແລະພວກເຮົາຈະສ້າງພາກສ່ວນຕ່າງໆເພື່ອສະແດງໃຫ້ທ່ານເຫັນຕົວຢ່າງຂອງການລັອກ.

ດັ່ງນັ້ນ, ຫນຶ່ງແຖວ, ຫນຶ່ງຖັນ. ປະເພດທໍາອິດຂອງການລັອກແມ່ນເອີ້ນວ່າ ACCESS SHARE. ນີ້ແມ່ນການຂັດຂວາງຫນ້ອຍທີ່ສຸດ. ນີ້ຫມາຍຄວາມວ່າມັນປະຕິບັດບໍ່ໄດ້ຂັດກັບ locks ອື່ນໆ.

ແລະຖ້າພວກເຮົາຕ້ອງການກໍານົດ lock ຢ່າງຊັດເຈນ, ພວກເຮົາດໍາເນີນການຄໍາສັ່ງ "lock table". ແລະແນ່ນອນຈະຕັນ, i.e. ໃນໂຫມດ ACCESS SHARE ພວກເຮົາເປີດຕົວຕາຕະລາງລັອກ. ແລະຖ້າຂ້ອຍແລ່ນ PSQL ໃນພື້ນຫລັງ, ຫຼັງຈາກນັ້ນຂ້ອຍເລີ່ມຕົ້ນກອງປະຊຸມທີສອງຈາກກອງປະຊຸມຄັ້ງທໍາອິດຂອງຂ້ອຍດ້ວຍວິທີນີ້. ນັ້ນແມ່ນ, ຂ້ອຍຈະເຮັດແນວໃດຢູ່ທີ່ນີ້? ຂ້ອຍໄປຫາກອງປະຊຸມອື່ນແລະບອກມັນວ່າ "ສະແດງໃຫ້ຂ້ອຍເຫັນ lockview ສໍາລັບການຮ້ອງຂໍນີ້." ແລະນີ້ຂ້ອຍມີ AccessShareLock ໃນຕາຕະລາງນີ້. ນີ້ແມ່ນສິ່ງທີ່ຂ້ອຍຮ້ອງຂໍ. ແລະລາວເວົ້າວ່າຕັນໄດ້ຖືກມອບຫມາຍ. ງ່າຍດາຍຫຼາຍ.

ນອກຈາກນັ້ນ, ຖ້າພວກເຮົາເບິ່ງຢູ່ໃນຄໍລໍາທີສອງ, ຫຼັງຈາກນັ້ນບໍ່ມີຫຍັງຢູ່ທີ່ນັ້ນ. ພວກເຂົາຫວ່າງເປົ່າ.

ແລະຖ້າຂ້ອຍດໍາເນີນການຄໍາສັ່ງ "SELECT", ນີ້ແມ່ນວິທີ implicit (explicit) ເພື່ອຮ້ອງຂໍ AccessShareLock. ດັ່ງນັ້ນຂ້ອຍປ່ອຍຕາຕະລາງຂອງຂ້ອຍແລະດໍາເນີນການສອບຖາມແລະການສອບຖາມກັບຄືນມາຫຼາຍແຖວ. ແລະຢູ່ໃນເສັ້ນຫນຶ່ງທີ່ພວກເຮົາເຫັນ AccessShareLock. ດັ່ງນັ້ນ, SELECT ໂທຫາ AccessShareLock ໃນຕາຕະລາງ. ແລະມັນບໍ່ໄດ້ຂັດແຍ້ງກັບ virtually ຫຍັງເພາະວ່າມັນເປັນການລັອກລະດັບຕ່ໍາ.

ຈະເປັນແນວໃດຖ້າຂ້ອຍດໍາເນີນການ SELECT ແລະມີສາມຕາຕະລາງທີ່ແຕກຕ່າງກັນ? ກ່ອນຫນ້ານີ້ຂ້ອຍແລ່ນພຽງແຕ່ຕາຕະລາງດຽວ, ຕອນນີ້ຂ້ອຍແລ່ນສາມ: pg_class, pg_namespace ແລະ pg_attribute.

ແລະຕອນນີ້ເມື່ອຂ້ອຍເບິ່ງແບບສອບຖາມ, ຂ້ອຍເຫັນ 9 AccessShareLocks ໃນສາມຕາຕະລາງ. ເປັນຫຍັງ? ສາມຕາຕະລາງແມ່ນເນັ້ນໃສ່ສີຟ້າ: pg_attribute, pg_class, pg_namespace. ແຕ່ທ່ານຍັງສາມາດເຫັນໄດ້ວ່າດັດສະນີທັງຫມົດທີ່ຖືກກໍານົດໂດຍຜ່ານຕາຕະລາງເຫຼົ່ານີ້ຍັງມີ AccessShareLock.

ແລະນີ້ແມ່ນລັອກທີ່ປະຕິບັດບໍ່ໄດ້ຂັດແຍ້ງກັບຄົນອື່ນ. ແລະສິ່ງທີ່ມັນເຮັດແມ່ນພຽງແຕ່ປ້ອງກັນບໍ່ໃຫ້ພວກເຮົາຕັ້ງຕາຕະລາງໃຫມ່ໃນຂະນະທີ່ພວກເຮົາເລືອກມັນ. ມັນເຮັດໃຫ້ຄວາມຮູ້ສຶກ. ນັ້ນແມ່ນ, ຖ້າພວກເຮົາເລືອກຕາຕະລາງ, ມັນຈະຫາຍໄປໃນຂະນະນັ້ນ, ແລ້ວນີ້ແມ່ນຜິດພາດ, ດັ່ງນັ້ນ AccessShare ແມ່ນການລັອກລະດັບຕໍ່າທີ່ບອກພວກເຮົາວ່າ "ຢ່າວາງຕາຕະລາງນີ້ໃນຂະນະທີ່ຂ້ອຍເຮັດວຽກ". ໂດຍພື້ນຖານແລ້ວ, ນັ້ນແມ່ນສິ່ງທີ່ນາງເຮັດ.

ROW SHARE - lock ນີ້ແມ່ນແຕກຕ່າງກັນເລັກນ້ອຍ.

ໃຫ້​ເຮົາ​ໃຊ້​ຕົວ​ຢ່າງ. SELECT ROW SHARE ວິທີການລັອກແຕ່ລະແຖວເປັນແຕ່ລະແຖວ. ວິທີນີ້ບໍ່ມີໃຜສາມາດລຶບພວກມັນ ຫຼືປ່ຽນພວກມັນໄດ້ ໃນຂະນະທີ່ພວກເຮົາກຳລັງເບິ່ງພວກມັນຢູ່.

ດັ່ງນັ້ນ SHARE LOCK ເຮັດຫຍັງ? ພວກເຮົາເຫັນວ່າ ID ການເຮັດທຸລະກໍາແມ່ນ 681 ສໍາລັບ SELECT. ແລະນີ້ແມ່ນຫນ້າສົນໃຈ. ເກີດຫຍັງຂຶ້ນທີ່ນີ້? ຄັ້ງທໍາອິດທີ່ພວກເຮົາເຫັນຕົວເລກແມ່ນຢູ່ໃນພາກສະຫນາມ "Lock". ພວກເຮົາເອົາ ID ການເຮັດທຸລະກໍາແລະມັນບອກວ່າມັນຖືກສະກັດມັນຢູ່ໃນໂຫມດສະເພາະ. ທັງຫມົດທີ່ມັນເຮັດແມ່ນມັນບອກວ່າຂ້ອຍມີແຖວທີ່ຖືກລັອກທາງດ້ານເຕັກນິກຢູ່ບ່ອນໃດຫນຶ່ງໃນຕາຕະລາງ. ແຕ່​ລາວ​ບໍ່​ໄດ້​ບອກ​ວ່າ​ຢູ່​ໃສ. ພວກເຮົາຈະເບິ່ງນີ້ໃນລາຍລະອຽດເພີ່ມເຕີມເລັກນ້ອຍຕໍ່ມາ.

ໃນທີ່ນີ້ພວກເຮົາເວົ້າວ່າ lock ໄດ້ຖືກນໍາໃຊ້ໂດຍພວກເຮົາ.

ດັ່ງນັ້ນ, lock exclusive ເວົ້າຢ່າງຊັດເຈນວ່າມັນເປັນສະເພາະ. ແລະຖ້າທ່ານລຶບແຖວຢູ່ໃນຕາຕະລາງນີ້, ຫຼັງຈາກນັ້ນ, ນີ້ແມ່ນສິ່ງທີ່ຈະເກີດຂຶ້ນ, ດັ່ງທີ່ທ່ານສາມາດເບິ່ງເຫັນໄດ້.

SHARE EXCLUSIVE ແມ່ນການລັອກທີ່ຍາວກວ່າ.

ນີ້ແມ່ນຄຳສັ່ງການວິເຄາະ (ANALYZE) ທີ່ຈະໃຊ້.

SHARE LOCK - ທ່ານສາມາດລັອກໃນໂຫມດການແບ່ງປັນຢ່າງຊັດເຈນ.

ນອກນັ້ນທ່ານຍັງສາມາດສ້າງດັດສະນີທີ່ເປັນເອກະລັກ. ແລະຢູ່ທີ່ນັ້ນທ່ານສາມາດເບິ່ງ SHARE LOCK, ເຊິ່ງເປັນສ່ວນຫນຶ່ງຂອງພວກມັນ. ແລະມັນລັອກຕາຕະລາງແລະວາງ SHARE LOCK ໃສ່ມັນ.

ໂດຍຄ່າເລີ່ມຕົ້ນ, SHARE LOCK ໃນຕາຕະລາງຫມາຍຄວາມວ່າຄົນອື່ນສາມາດອ່ານຕາຕະລາງໄດ້, ແຕ່ບໍ່ມີໃຜສາມາດດັດແປງມັນໄດ້. ແລະນີ້ແມ່ນແທ້ສິ່ງທີ່ເກີດຂື້ນເມື່ອທ່ານສ້າງດັດສະນີທີ່ເປັນເອກະລັກ.

ຖ້າຂ້ອຍສ້າງດັດສະນີ concurrently ເປັນເອກະລັກ, ຫຼັງຈາກນັ້ນຂ້ອຍຈະມີປະເພດທີ່ແຕກຕ່າງກັນຂອງການລັອກເພາະວ່າ, ຕາມທີ່ທ່ານຈື່, ການນໍາໃຊ້ດັດສະນີ concurrently ຫຼຸດຜ່ອນຄວາມຕ້ອງການລັອກ. ແລະຖ້າຂ້ອຍໃຊ້ lock ປົກກະຕິ, ດັດສະນີປົກກະຕິ, ດັ່ງນັ້ນຂ້ອຍຈຶ່ງຈະປ້ອງກັນບໍ່ໃຫ້ຂຽນກັບຕາຕະລາງຕາຕະລາງໃນຂະນະທີ່ມັນຖືກສ້າງຂຶ້ນ. ຖ້າຂ້ອຍໃຊ້ດັດສະນີ concurrently, ຂ້ອຍຈໍາເປັນຕ້ອງໃຊ້ການລັອກປະເພດທີ່ແຕກຕ່າງກັນ.

ແບ່ງປັນແຖວແບບພິເສດ - ອີກເທື່ອຫນຶ່ງມັນສາມາດຖືກກໍານົດຢ່າງຊັດເຈນ (ຢ່າງຈະແຈ້ງ).

ຫຼືພວກເຮົາສາມາດສ້າງກົດລະບຽບ, i.e., ເອົາກໍລະນີສະເພາະໃດຫນຶ່ງທີ່ມັນຈະຖືກນໍາໃຊ້.

lock EXCLUSIVE ຫມາຍຄວາມວ່າບໍ່ມີໃຜສາມາດປ່ຽນຕາຕະລາງໄດ້.

ທີ່ນີ້ພວກເຮົາເຫັນປະເພດທີ່ແຕກຕ່າງກັນຂອງ locks.

ACCESS EXCLUSIVE, ສໍາລັບຕົວຢ່າງ, ເປັນຄໍາສັ່ງສະກັດ. ຕົວຢ່າງ, ຖ້າທ່ານເຮັດ CLUSTER table, ຫຼັງຈາກນັ້ນນີ້ຈະຫມາຍຄວາມວ່າບໍ່ມີໃຜຈະສາມາດຂຽນຢູ່ທີ່ນັ້ນ. ແລະມັນ locks ບໍ່ພຽງແຕ່ຕາຕະລາງຕົວມັນເອງ, ແຕ່ຍັງດັດສະນີ.

ນີ້ແມ່ນຫນ້າທີສອງຂອງການຂັດຂວາງການເຂົ້າເຖິງ, ບ່ອນທີ່ພວກເຮົາເຫັນສິ່ງທີ່ມັນຂັດຂວາງຢູ່ໃນຕາຕະລາງ. ມັນ locks ແຖວຕາຕະລາງສ່ວນບຸກຄົນ, ຊຶ່ງເປັນທີ່ຫນ້າສົນໃຈດີ.

ນັ້ນແມ່ນຂໍ້ມູນພື້ນຖານທັງຫມົດທີ່ຂ້ອຍຕ້ອງການໃຫ້. ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບການລັອກ, ກ່ຽວກັບ ID ການເຮັດທຸລະກໍາ, ພວກເຮົາໄດ້ເວົ້າກ່ຽວກັບ ID ການເຮັດທຸລະກໍາ virtual, ກ່ຽວກັບ ID ການເຮັດທຸລະກໍາຖາວອນ.

ແລະຕອນນີ້ພວກເຮົາຈະຜ່ານຕົວຢ່າງການຂັດຂວາງບາງຢ່າງ. ນີ້ແມ່ນສ່ວນທີ່ຫນ້າສົນໃຈທີ່ສຸດ. ພວກເຮົາຈະເບິ່ງກໍລະນີທີ່ຫນ້າສົນໃຈຫຼາຍ. ແລະເປົ້າຫມາຍຂອງຂ້ອຍໃນການນໍາສະເຫນີນີ້ແມ່ນເພື່ອໃຫ້ເຈົ້າເຂົ້າໃຈດີຂຶ້ນກ່ຽວກັບສິ່ງທີ່ Postgres ກໍາລັງເຮັດໃນເວລາທີ່ມັນພະຍາຍາມສະກັດບາງສິ່ງທີ່ແນ່ນອນ. ຂ້ອຍຄິດວ່າລາວເກັ່ງຫຼາຍໃນການສະກັດພາກສ່ວນຕ່າງໆ.

ໃຫ້​ເຮົາ​ມາ​ເບິ່ງ​ບາງ​ຕົວ​ຢ່າງ​ສະເພາະ.

ພວກເຮົາຈະເລີ່ມຕົ້ນດ້ວຍຕາຕະລາງແລະແຖວຫນຶ່ງໃນຕາຕະລາງ. ເມື່ອຂ້ອຍໃສ່ບາງສິ່ງບາງຢ່າງຂ້ອຍມີ ExclusiveLock, Transaction ID ແລະ ExclusiveLock ສະແດງຢູ່ໃນຕາຕະລາງ.

ຈະເກີດຫຍັງຂຶ້ນຖ້າຂ້ອຍໃສ່ສອງແຖວຕື່ມອີກ? ແລະໃນປັດຈຸບັນຕາຕະລາງຂອງພວກເຮົາມີສາມແຖວ. ແລະຂ້ອຍໃສ່ແຖວຫນຶ່ງແລະໄດ້ຮັບນີ້ເປັນຜົນຜະລິດ. ແລະຖ້າຂ້ອຍໃສ່ສອງແຖວຕື່ມອີກ, ສິ່ງທີ່ແປກປະຫຼາດກ່ຽວກັບເລື່ອງນັ້ນ? ມີສິ່ງແປກປະຫລາດຢູ່ທີ່ນີ້ເພາະວ່າຂ້ອຍໄດ້ເພີ່ມສາມແຖວໃສ່ຕາຕະລາງນີ້, ແຕ່ຂ້ອຍຍັງມີສອງແຖວຢູ່ໃນຕາຕະລາງລັອກ. ແລະນີ້ເປັນສິ່ງຈໍາເປັນພຶດຕິກໍາພື້ນຖານຂອງ Postgres.

ຫຼາຍຄົນຄິດວ່າຖ້າຢູ່ໃນຖານຂໍ້ມູນເຈົ້າລັອກ 100 ແຖວ, ຫຼັງຈາກນັ້ນເຈົ້າຈະຕ້ອງສ້າງ 100 ລາຍການລັອກ. ຖ້າຂ້ອຍບລັອກ 1 ແຖວໃນເວລາດຽວກັນ, ຂ້ອຍຈະຕ້ອງການ 000 ຄໍາຖາມດັ່ງກ່າວ. ແລະຖ້າຂ້ອຍຕ້ອງການຫນຶ່ງລ້ານຫຼືຫຼາຍຕື້ເພື່ອຕັນ. ແຕ່ຖ້າພວກເຮົາເຮັດແນວນີ້, ມັນຈະບໍ່ດີຫຼາຍ. ຖ້າທ່ານໄດ້ນໍາໃຊ້ລະບົບທີ່ສ້າງການຂັດຂວາງສໍາລັບແຕ່ລະແຖວແຕ່ລະຄົນ, ຫຼັງຈາກນັ້ນທ່ານສາມາດເຫັນໄດ້ວ່ານີ້ແມ່ນສັບສົນ. ເນື່ອງຈາກວ່າທ່ານຈໍາເປັນຕ້ອງກໍານົດຕາຕະລາງ lock ທັນທີທີ່ສາມາດ overflow, ແຕ່ Postgres ບໍ່ໄດ້ເຮັດແນວນັ້ນ.

ແລະສິ່ງທີ່ສໍາຄັນແທ້ໆກ່ຽວກັບສະໄລ້ນີ້ແມ່ນວ່າມັນສະແດງໃຫ້ເຫັນຢ່າງຈະແຈ້ງວ່າມີລະບົບອື່ນທີ່ເຮັດວຽກຢູ່ໃນ MVCC ທີ່ລັອກແຕ່ລະແຖວ. ດັ່ງນັ້ນ, ໃນເວລາທີ່ທ່ານລັອກຫຼາຍຕື້ແຖວ, Postgres ບໍ່ໄດ້ສ້າງເປັນພັນລ້ານຄໍາສັ່ງລັອກແຍກຕ່າງຫາກ. ແລະນີ້ມີຜົນກະທົບທີ່ດີຫຼາຍຕໍ່ຜົນຜະລິດ.

ແມ່ນຫຍັງກ່ຽວກັບການອັບເດດ? ຂ້ອຍກໍາລັງປັບປຸງແຖວໃນປັດຈຸບັນ, ແລະເຈົ້າສາມາດເຫັນໄດ້ວ່າມັນໄດ້ປະຕິບັດສອງຢ່າງທີ່ແຕກຕ່າງກັນໃນເວລາດຽວກັນ. ມັນລັອກຕາຕະລາງໃນເວລາດຽວກັນ, ແຕ່ມັນຍັງລັອກດັດຊະນີ. ແລະລາວຕ້ອງການລັອກດັດຊະນີເພາະວ່າມີຂໍ້ຈໍາກັດທີ່ເປັນເອກະລັກໃນຕາຕະລາງນີ້. ແລະພວກເຮົາຕ້ອງການໃຫ້ແນ່ໃຈວ່າບໍ່ມີໃຜປ່ຽນແປງມັນ, ດັ່ງນັ້ນພວກເຮົາສະກັດມັນ.

ຈະເກີດຫຍັງຂຶ້ນຖ້າຂ້ອຍຕ້ອງການອັບເດດສອງແຖວ? ແລະ​ພວກ​ເຮົາ​ເຫັນ​ວ່າ​ລາວ​ປະພຶດ​ແບບ​ດຽວ​ກັນ. ພວກ​ເຮົາ​ເຮັດ​ການ​ປັບ​ປຸງ​ເປັນ​ສອງ​ເທົ່າ​, ແຕ່​ວ່າ​ຈໍາ​ນວນ​ດຽວ​ກັນ​ຂອງ​ສາຍ lock​.

ຖ້າເຈົ້າສົງໄສວ່າ Postgres ເຮັດແນວນີ້ແນວໃດ, ເຈົ້າຈະຕ້ອງໄດ້ຟັງການໂອ້ລົມຂອງຂ້ອຍຢູ່ MVCC ເພື່ອຮຽນຮູ້ວ່າ Postgres ພາຍໃນໝາຍເຖິງສາຍເຫຼົ່ານີ້ທີ່ມັນປ່ຽນແປງແນວໃດ. ແລະ Postgres ມີວິທີການທີ່ມັນເຮັດສິ່ງນີ້, ແຕ່ມັນບໍ່ໄດ້ເຮັດມັນຢູ່ໃນລະດັບການລັອກຕາຕະລາງ, ມັນເຮັດຢູ່ໃນລະດັບຕ່ໍາກວ່າແລະມີປະສິດທິພາບຫຼາຍ.

ຈະເປັນແນວໃດຖ້າຂ້ອຍຕ້ອງການລຶບບາງສິ່ງບາງຢ່າງ? ຖ້າຂ້ອຍລຶບ, ສໍາລັບການຍົກຕົວຢ່າງ, ແຖວຫນຶ່ງແລະຂ້ອຍຍັງມີສອງຕົວສະກັດຂອງຂ້ອຍ, ແລະເຖິງແມ່ນວ່າຂ້ອຍຕ້ອງການລຶບພວກມັນທັງຫມົດ, ພວກມັນຍັງມີຢູ່.

ແລະ, ສໍາລັບການຍົກຕົວຢ່າງ, ຂ້ອຍຕ້ອງການໃສ່ 1 ເສັ້ນ, ແລະຫຼັງຈາກນັ້ນລຶບຫຼືເພີ່ມ 000 ເສັ້ນ, ຫຼັງຈາກນັ້ນເສັ້ນສ່ວນບຸກຄົນເຫຼົ່ານັ້ນທີ່ຂ້ອຍເພີ່ມຫຼືປ່ຽນ, ພວກມັນບໍ່ໄດ້ຖືກບັນທຶກຢູ່ທີ່ນີ້. ພວກເຂົາເຈົ້າໄດ້ຖືກຂຽນຢູ່ໃນລະດັບຕ່ໍາພາຍໃນຊຸດຕົວມັນເອງ. ແລະໃນລະຫວ່າງການປາກເວົ້າຂອງ MVCC ຂ້າພະເຈົ້າໄດ້ເວົ້າກ່ຽວກັບເລື່ອງນີ້ຢ່າງລະອຽດ. ແຕ່ມັນເປັນສິ່ງສໍາຄັນຫຼາຍໃນເວລາທີ່ທ່ານກໍາລັງວິເຄາະການລັອກເພື່ອໃຫ້ແນ່ໃຈວ່າທ່ານກໍາລັງລັອກຢູ່ໃນລະດັບຕາຕະລາງແລະທ່ານບໍ່ເຫັນວິທີການບັນທຶກແຖວແຕ່ລະຄົນຢູ່ທີ່ນີ້.

ແມ່ນຫຍັງກ່ຽວກັບການຂັດຂວາງຢ່າງຈະແຈ້ງ?

ຖ້າຂ້ອຍຄລິກ refresh, ຂ້ອຍມີສອງແຖວຖືກລັອກ. ແລະຖ້າຂ້ອຍເລືອກພວກມັນທັງຫມົດແລະຄລິກໃສ່ "ອັບເດດຢູ່ທົ່ວທຸກແຫ່ງ," ຫຼັງຈາກນັ້ນຂ້ອຍຍັງມີສອງບັນທຶກການຂັດຂວາງ.

ພວກເຮົາບໍ່ໄດ້ສ້າງບັນທຶກແຍກຕ່າງຫາກສໍາລັບແຕ່ລະແຖວແຕ່ລະຄົນ. ເນື່ອງຈາກວ່າຫຼັງຈາກນັ້ນຜົນຜະລິດຫຼຸດລົງ, ມັນອາດຈະມີຫຼາຍເກີນໄປ. ແລະ​ເຮົາ​ອາດ​ພົບ​ຕົວ​ເອງ​ຢູ່​ໃນ​ສະ​ພາບ​ທີ່​ບໍ່​ພໍ​ໃຈ.

ແລະສິ່ງດຽວກັນ, ຖ້າພວກເຮົາແບ່ງປັນ, ພວກເຮົາສາມາດເຮັດໄດ້ທັງຫມົດ 30 ເທື່ອ.

ພວກເຮົາຟື້ນຟູຕາຕະລາງຂອງພວກເຮົາ, ລຶບທຸກສິ່ງທຸກຢ່າງ, ຫຼັງຈາກນັ້ນໃສ່ແຖວຫນຶ່ງອີກເທື່ອຫນຶ່ງ.

ພຶດຕິກໍາອື່ນທີ່ເຈົ້າເຫັນໃນ Postgres ເປັນທີ່ຮູ້ຈັກຫຼາຍແລະພຶດຕິກໍາທີ່ຕ້ອງການແມ່ນວ່າທ່ານສາມາດປັບປຸງຫຼືເລືອກ. ແລະທ່ານສາມາດເຮັດສິ່ງນີ້ໃນເວລາດຽວກັນ. ແລະເລືອກບໍ່ໄດ້ຂັດຂວາງການປັບປຸງແລະສິ່ງດຽວກັນໃນທິດທາງກົງກັນຂ້າມ. ພວກເຮົາບອກຜູ້ອ່ານວ່າຢ່າປິດກັ້ນນັກຂຽນ, ແລະນັກຂຽນບໍ່ໄດ້ຂັດຂວາງຜູ້ອ່ານ.

ຂ້ອຍຈະສະແດງຕົວຢ່າງຂອງເລື່ອງນີ້. ຂ້ອຍຈະເລືອກດຽວນີ້. ຫຼັງຈາກນັ້ນພວກເຮົາຈະເຮັດ INSERT. ແລະຫຼັງຈາກນັ້ນທ່ານສາມາດເບິ່ງ - 694. ທ່ານສາມາດເບິ່ງ ID ຂອງທຸລະກໍາທີ່ປະຕິບັດການແຊກນີ້. ແລະນັ້ນແມ່ນວິທີທີ່ມັນເຮັດວຽກ.

ແລະຖ້າຂ້ອຍເບິ່ງ backend ID ຂອງຂ້ອຍດຽວນີ້, ມັນແມ່ນ 695.

ແລະຂ້ອຍສາມາດເຫັນ 695 ປາກົດຢູ່ໃນຕາຕະລາງຂອງຂ້ອຍ.

ແລະຖ້າຂ້ອຍປັບປຸງຢູ່ທີ່ນີ້ເຊັ່ນນີ້, ຂ້ອຍຈະໄດ້ຮັບກໍລະນີທີ່ແຕກຕ່າງກັນ. ໃນກໍລະນີນີ້, 695 ແມ່ນການລັອກສະເພາະ, ແລະການປັບປຸງມີພຶດຕິກໍາດຽວກັນ, ແຕ່ບໍ່ມີຂໍ້ຂັດແຍ່ງລະຫວ່າງພວກເຂົາ, ເຊິ່ງຂ້ອນຂ້າງຜິດປົກກະຕິ.

ແລະທ່ານສາມາດເຫັນໄດ້ວ່າຢູ່ເທິງສຸດມັນແມ່ນ ShareLock, ແລະຢູ່ດ້ານລຸ່ມມັນແມ່ນ ExclusiveLock. ແລະທັງສອງທຸລະກໍາເຮັດວຽກອອກ.

ແລະເຈົ້າຈໍາເປັນຕ້ອງໄດ້ຟັງການສົນທະນາຂອງຂ້ອຍຢູ່ MVCC ເພື່ອເຂົ້າໃຈວິທີນີ້ເກີດຂຶ້ນ. ແຕ່ນີ້ແມ່ນຕົວຢ່າງທີ່ທ່ານສາມາດເຮັດໄດ້ໃນເວລາດຽວກັນ, i.e. ເຮັດ SELECT ແລະ UPDATE ໃນເວລາດຽວກັນ.

ມາຣີເຊັດ ແລະເຮັດອີກອັນໜຶ່ງການດຳເນີນການ.

ຖ້າທ່ານພະຍາຍາມດໍາເນີນການປັບປຸງສອງຄັ້ງພ້ອມກັນໃນແຖວດຽວກັນ, ມັນຈະຖືກບລັອກ. ແລະຈື່, ຂ້າພະເຈົ້າໄດ້ເວົ້າວ່າຜູ້ອ່ານບໍ່ໄດ້ຂັດຂວາງນັກຂຽນ, ແລະນັກຂຽນບໍ່ໄດ້ຂັດຂວາງຜູ້ອ່ານ, ແຕ່ນັກຂຽນຄົນຫນຶ່ງຂັດຂວາງນັກຂຽນອື່ນ. ນັ້ນແມ່ນ, ພວກເຮົາບໍ່ສາມາດມີສອງຄົນປັບປຸງແຖວດຽວກັນໃນເວລາດຽວກັນ. ທ່ານຕ້ອງລໍຖ້າຈົນກ່ວາຫນຶ່ງໃນນັ້ນສໍາເລັດ.

ແລະເພື່ອສະແດງໃຫ້ເຫັນເລື່ອງນີ້, ຂ້ອຍຈະເບິ່ງຕາຕະລາງ Lockdemo. ແລະພວກເຮົາຈະເບິ່ງແຖວຫນຶ່ງ. ຕໍ່ທຸລະກຳ 698.

ພວກເຮົາໄດ້ປັບປຸງນີ້ເປັນ 2. 699 ແມ່ນການປັບປຸງຄັ້ງທໍາອິດ. ແລະມັນປະສົບຜົນສໍາເລັດຫຼືມັນຢູ່ໃນທຸລະກໍາທີ່ຍັງຄ້າງຢູ່ແລະລໍຖ້າໃຫ້ພວກເຮົາຢືນຢັນຫຼືຍົກເລີກ.

ແຕ່ເບິ່ງສິ່ງອື່ນ - 2/51 ແມ່ນການເຮັດທຸລະກໍາຄັ້ງທໍາອິດຂອງພວກເຮົາ, ກອງປະຊຸມຄັ້ງທໍາອິດຂອງພວກເຮົາ. 3/112 ແມ່ນຄໍາຮ້ອງຂໍທີສອງທີ່ມາຈາກທາງເທິງທີ່ປ່ຽນຄ່ານັ້ນເປັນ 3. ແລະຖ້າທ່ານສັງເກດເຫັນ, ເທິງໄດ້ລັອກຕົວມັນເອງ, ເຊິ່ງແມ່ນ 699. ແຕ່ 3/112 ບໍ່ໄດ້ໃຫ້ lock. ຖັນ Lock_mode ເວົ້າວ່າສິ່ງທີ່ມັນລໍຖ້າຢູ່. ມັນຄາດວ່າ 699. ແລະຖ້າທ່ານເບິ່ງບ່ອນທີ່ 699 ແມ່ນ, ມັນສູງກວ່າ. ແລະກອງປະຊຸມຄັ້ງທໍາອິດໄດ້ເຮັດຫຍັງ? ນາງສ້າງການລັອກສະເພາະໃນລະຫັດທຸລະກໍາຂອງຕົນເອງ. ນີ້ແມ່ນວິທີທີ່ Postgres ເຮັດມັນ. ມັນບລັອກ ID ການເຮັດທຸລະກໍາຂອງຕົນເອງ. ແລະຖ້າທ່ານຕ້ອງການລໍຖ້າຜູ້ໃດຜູ້ຫນຶ່ງຢືນຢັນຫຼືຍົກເລີກ, ຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງລໍຖ້າໃນຂະນະທີ່ມີທຸລະກໍາທີ່ຍັງຄ້າງຢູ່. ແລະນັ້ນແມ່ນເຫດຜົນທີ່ພວກເຮົາສາມາດເຫັນເສັ້ນແປກ.

ໃຫ້ເບິ່ງອີກເທື່ອຫນຶ່ງ. ຢູ່ເບື້ອງຊ້າຍພວກເຮົາເຫັນ ID ການປະມວນຜົນຂອງພວກເຮົາ. ໃນຖັນທີສອງພວກເຮົາເຫັນ ID ການເຮັດທຸລະກໍາ virtual ຂອງພວກເຮົາ, ແລະໃນທີສາມພວກເຮົາເຫັນ lock_type. ນີ້ຫມາຍຄວາມວ່າແນວໃດ? ໂດຍພື້ນຖານແລ້ວສິ່ງທີ່ມັນເວົ້າແມ່ນວ່າມັນຖືກບລັອກ ID ການເຮັດທຸລະກໍາ. ແຕ່ສັງເກດເຫັນວ່າແຖວທັງຫມົດຢູ່ທາງລຸ່ມເວົ້າວ່າການພົວພັນ. ແລະດັ່ງນັ້ນທ່ານມີສອງປະເພດຂອງ locks ໃນຕາຕະລາງ. ມີການລັອກຄວາມສໍາພັນ. ແລະຫຼັງຈາກນັ້ນມີການຂັດຂວາງການເຮັດທຸລະກໍາ, ບ່ອນທີ່ທ່ານປິດກັ້ນດ້ວຍຕົວຂອງທ່ານເອງ, ເຊິ່ງເປັນສິ່ງທີ່ເກີດຂື້ນໃນແຖວທໍາອິດຫຼືຢູ່ລຸ່ມສຸດ, ບ່ອນທີ່ການເຮັດທຸລະກໍາຢູ່, ບ່ອນທີ່ພວກເຮົາລໍຖ້າ 699 ສໍາເລັດການປະຕິບັດງານຂອງມັນ.

ຂ້ອຍຈະເຫັນສິ່ງທີ່ເກີດຂື້ນຢູ່ທີ່ນີ້. ແລະໃນທີ່ນີ້ສອງສິ່ງເກີດຂຶ້ນພ້ອມໆກັນ. ທ່ານກຳລັງເບິ່ງການລັອກ ID ທຸລະກຳຢູ່ໃນແຖວທຳອິດທີ່ລັອກຕົວມັນເອງ. ແລະນາງຕັນຕົນເອງເພື່ອເຮັດໃຫ້ປະຊາຊົນລໍຖ້າ.

ຖ້າເບິ່ງໃນແຖວທີ 6, ມັນແມ່ນການເຂົ້າດຽວກັນກັບເສັ້ນທໍາອິດ. ແລະດັ່ງນັ້ນການເຮັດທຸລະກໍາ 699 ຖືກບລັອກ. 700 ແມ່ນຍັງລັອກດ້ວຍຕົນເອງ. ແລະຫຼັງຈາກນັ້ນຢູ່ໃນແຖວລຸ່ມທ່ານຈະເຫັນວ່າພວກເຮົາກໍາລັງລໍຖ້າ 699 ເພື່ອສໍາເລັດການປະຕິບັດງານຂອງມັນ.

ແລະໃນ lock_type, tuple ທ່ານຈະເຫັນຕົວເລກ.

ເຈົ້າສາມາດເຫັນໄດ້ວ່າ 0/10. ແລະນີ້ແມ່ນຈໍານວນຫນ້າ, ແລະຍັງເປັນການຊົດເຊີຍຂອງແຖວສະເພາະນີ້.

ແລະທ່ານເຫັນວ່າມັນກາຍເປັນ 0/11 ເມື່ອພວກເຮົາປັບປຸງ.

ແຕ່ໃນຄວາມເປັນຈິງແລ້ວມັນແມ່ນ 0/10, ເພາະວ່າມີການລໍຖ້າການດໍາເນີນງານນີ້. ພວກເຮົາມີໂອກາດທີ່ຈະເຫັນວ່ານີ້ແມ່ນຊຸດທີ່ຂ້ອຍລໍຖ້າການຢືນຢັນ.

ເມື່ອພວກເຮົາຢືນຢັນມັນແລະກົດ commit, ແລະເມື່ອການປັບປຸງສໍາເລັດ, ນີ້ແມ່ນສິ່ງທີ່ພວກເຮົາໄດ້ຮັບອີກເທື່ອຫນຶ່ງ. ການເຮັດທຸລະກໍາ 700 ແມ່ນການລັອກອັນດຽວ, ມັນບໍ່ໄດ້ລໍຖ້າຜູ້ອື່ນເພາະວ່າມັນຫມັ້ນສັນຍາ. ມັນພຽງແຕ່ລໍຖ້າການເຮັດທຸລະກໍາສໍາເລັດ. ເມື່ອ 699 ໝົດ, ພວກເຮົາບໍ່ລໍຖ້າຫຍັງອີກຕໍ່ໄປ. ແລະໃນປັດຈຸບັນການເຮັດທຸລະກໍາ 700 ເວົ້າວ່າທຸກສິ່ງທຸກຢ່າງແມ່ນດີ, ມັນມີ locks ທັງຫມົດທີ່ມັນຕ້ອງການຢູ່ໃນຕາຕະລາງທີ່ອະນຸຍາດທັງຫມົດ.

ແລະເພື່ອເຮັດໃຫ້ສິ່ງທັງຫມົດນີ້ສັບສົນຫຼາຍ, ພວກເຮົາສ້າງທັດສະນະອື່ນ, ເຊິ່ງເວລານີ້ຈະສະຫນອງພວກເຮົາດ້ວຍລໍາດັບຊັ້ນ. ຂ້ອຍບໍ່ຄາດຫວັງວ່າເຈົ້າຈະເຂົ້າໃຈຄໍາຮ້ອງຂໍນີ້. ແຕ່ນີ້ຈະເຮັດໃຫ້ພວກເຮົາມີທັດສະນະທີ່ຊັດເຈນກວ່າກ່ຽວກັບສິ່ງທີ່ເກີດຂຶ້ນ.

ນີ້ແມ່ນທັດສະນະ recursive ທີ່ຍັງມີພາກອື່ນ. ແລະຫຼັງຈາກນັ້ນມັນເອົາທຸກສິ່ງທຸກຢ່າງກັບຄືນມາຮ່ວມກັນອີກເທື່ອຫນຶ່ງ. ໃຫ້ໃຊ້ອັນນີ້.

ຈະເປັນແນວໃດຖ້າພວກເຮົາເຮັດສາມການປັບປຸງພ້ອມໆກັນແລະເວົ້າວ່າແຖວນີ້ແມ່ນສາມ. ແລະພວກເຮົາຈະປ່ຽນ 3 ຫາ 4.

ແລະໃນທີ່ນີ້ພວກເຮົາເບິ່ງ 4. ແລະ ID ການເຮັດທຸລະກໍາ 702.

ແລະຫຼັງຈາກນັ້ນຂ້ອຍຈະປ່ຽນ 4 ຫາ 5. ແລະ 5 ຫາ 6, ແລະ 6 ຫາ 7. ແລະຂ້ອຍຈະແຖວຈໍານວນຄົນທີ່ຈະລໍຖ້າການເຮັດທຸລະກໍາຫນຶ່ງນີ້ສິ້ນສຸດລົງ.

ແລະທຸກສິ່ງທຸກຢ່າງຈະກາຍເປັນທີ່ຈະແຈ້ງ. ແຖວທຳອິດແມ່ນຫຍັງ? ນີ້ແມ່ນ 702. ນີ້ແມ່ນລະຫັດທຸລະກໍາທີ່ກໍານົດຄ່ານີ້ໃນເບື້ອງຕົ້ນ. ແມ່ນຫຍັງຂຽນຢູ່ໃນຄໍລໍາທີ່ໄດ້ຮັບອະນຸຍາດຂອງຂ້ອຍ? ຂ້ອຍມີເຄື່ອງຫມາຍ f. ນີ້ແມ່ນການປັບປຸງຂອງຂ້ອຍທີ່ (5, 6, 7) ບໍ່ສາມາດອະນຸມັດໄດ້ເພາະວ່າພວກເຮົາລໍຖ້າການເຮັດທຸລະກໍາ ID 702 ສິ້ນສຸດລົງ. ຢູ່ທີ່ນັ້ນພວກເຮົາມີການປິດກັ້ນ ID ການເຮັດທຸລະກໍາ. ແລະນີ້ເຮັດໃຫ້ 5 ລັອກ ID ການເຮັດທຸລະກໍາ.

ແລະຖ້າທ່ານເບິ່ງ 704, ຢູ່ທີ່ 705, ບໍ່ມີຫຍັງຖືກຂຽນຢູ່ທີ່ນັ້ນ, ເພາະວ່າພວກເຂົາບໍ່ຮູ້ວ່າມີຫຍັງເກີດຂື້ນ. ພວກເຂົາພຽງແຕ່ຂຽນວ່າພວກເຂົາບໍ່ຮູ້ວ່າມີຫຍັງເກີດຂຶ້ນ. ແລະພວກເຂົາພຽງແຕ່ຈະໄປນອນເພາະວ່າພວກເຂົາລໍຖ້າໃຫ້ຄົນສໍາເລັດຮູບແລະຕື່ນຂຶ້ນເມື່ອມີໂອກາດທີ່ຈະປ່ຽນແຖວ.

ນີ້ແມ່ນສິ່ງທີ່ມັນຄ້າຍຄື. ມັນເປັນທີ່ຊັດເຈນວ່າພວກເຂົາທັງຫມົດກໍາລັງລໍຖ້າສາຍທີ 12.

ນີ້ແມ່ນສິ່ງທີ່ພວກເຮົາໄດ້ເຫັນຢູ່ທີ່ນີ້. ນີ້ແມ່ນ 0/12.

ດັ່ງນັ້ນເມື່ອທຸລະກໍາທໍາອິດໄດ້ຮັບການອະນຸມັດ, ທ່ານສາມາດເບິ່ງທີ່ນີ້ວິທີການລໍາດັບຊັ້ນເຮັດວຽກ. ແລະໃນປັດຈຸບັນທຸກສິ່ງທຸກຢ່າງກາຍເປັນທີ່ຈະແຈ້ງ. ພວກເຂົາທັງຫມົດກາຍເປັນສະອາດ. ແລະຕົວຈິງແລ້ວພວກເຂົາຍັງລໍຖ້າຢູ່.

ນີ້ແມ່ນສິ່ງທີ່ເກີດຂຶ້ນ. 702 ຄໍາຫມັ້ນສັນຍາ. ແລະໃນປັດຈຸບັນ 703 ໄດ້ຮັບການລັອກແຖວນີ້, ແລະຫຼັງຈາກນັ້ນ 704 ເລີ່ມຕົ້ນລໍຖ້າ 703 ຫມັ້ນສັນຍາ. ແລະ 705 ກໍາລັງລໍຖ້ານີ້ຄືກັນ. ແລະ​ເມື່ອ​ສິ່ງ​ທັງ​ໝົດ​ນີ້​ສຳ​ເລັດ​ແລ້ວ, ພວກ​ເຂົາ​ເຈົ້າ​ກໍ​ທຳ​ຄວາມ​ສະ​ອາດ. ແລະຂ້າພະເຈົ້າຢາກຈະຊີ້ໃຫ້ເຫັນວ່າທຸກຄົນແມ່ນ line up. ແລະນີ້ແມ່ນຄ້າຍຄືກັນກັບສະຖານະການການຈະລາຈອນຕິດຂັດໃນເວລາທີ່ທຸກຄົນລໍຖ້າລົດທໍາອິດ. ລົດຄັນທຳອິດຢຸດ ແລະ ທຸກຄົນຂຶ້ນແຖວເປັນແຖວຍາວ. ຫຼັງຈາກນັ້ນ, ມັນເຄື່ອນຍ້າຍ, ຫຼັງຈາກນັ້ນລົດຕໍ່ໄປສາມາດຂັບລົດໄປຂ້າງຫນ້າແລະໄດ້ຮັບການສະກັດຂອງມັນ, ແລະອື່ນໆ.

ແລະຖ້າມັນເບິ່ງຄືວ່າບໍ່ສັບສົນພຽງພໍກັບເຈົ້າ, ດຽວນີ້ພວກເຮົາຈະເວົ້າກັບເຈົ້າກ່ຽວກັບການປິດປະຕູ. ຂ້ອຍບໍ່ຮູ້ວ່າເຈົ້າຄົນໃດໄດ້ພົບກັບພວກມັນ. ນີ້ແມ່ນບັນຫາທົ່ວໄປພໍສົມຄວນໃນລະບົບຖານຂໍ້ມູນ. ແຕ່ການຢຸດຊະງັກແມ່ນເວລາທີ່ກອງປະຊຸມຫນຶ່ງລໍຖ້າກອງປະຊຸມອື່ນເພື່ອເຮັດບາງສິ່ງບາງຢ່າງ. ແລະໃນເວລານີ້ກອງປະຊຸມອື່ນກໍາລັງລໍຖ້າກອງປະຊຸມທໍາອິດທີ່ຈະເຮັດບາງສິ່ງບາງຢ່າງ.

ແລະ, ສໍາລັບການຍົກຕົວຢ່າງ, ຖ້າ Ivan ເວົ້າວ່າ: "ໃຫ້ຂ້ອຍບາງສິ່ງບາງຢ່າງ," ແລະຂ້ອຍເວົ້າວ່າ: "ບໍ່, ຂ້ອຍຈະໃຫ້ມັນກັບເຈົ້າເທົ່ານັ້ນຖ້າທ່ານເອົາສິ່ງອື່ນໃຫ້ຂ້ອຍ." ແລະລາວເວົ້າວ່າ, "ບໍ່, ຂ້ອຍຈະບໍ່ເອົາມັນໃຫ້ເຈົ້າຖ້າເຈົ້າບໍ່ໃຫ້ຂ້ອຍ." ແລະພວກເຮົາສິ້ນສຸດລົງໃນສະຖານະການ deadlock. ຂ້ອຍແນ່ໃຈວ່າ Ivan ຈະບໍ່ເຮັດແນວນີ້, ແຕ່ເຈົ້າເຂົ້າໃຈຄວາມຫມາຍວ່າພວກເຮົາມີສອງຄົນທີ່ຢາກໄດ້ບາງສິ່ງບາງຢ່າງແລະພວກເຂົາບໍ່ພ້ອມທີ່ຈະໃຫ້ມັນໄປຈົນກວ່າຄົນອື່ນຈະໃຫ້ສິ່ງທີ່ພວກເຂົາຕ້ອງການ. ແລະບໍ່ມີການແກ້ໄຂ.

ແລະສໍາຄັນ, ຖານຂໍ້ມູນຂອງທ່ານຕ້ອງການກວດພົບນີ້. ແລະຫຼັງຈາກນັ້ນທ່ານຈໍາເປັນຕ້ອງລຶບຫຼືປິດຫນຶ່ງຂອງເຊດຊັນ, ເພາະວ່າຖ້າບໍ່ດັ່ງນັ້ນພວກມັນຈະຢູ່ທີ່ນັ້ນຕະຫຼອດໄປ. ແລະພວກເຮົາເຫັນມັນຢູ່ໃນຖານຂໍ້ມູນ, ພວກເຮົາເຫັນມັນຢູ່ໃນລະບົບປະຕິບັດການ. ແລະໃນສະຖານທີ່ທັງຫມົດທີ່ພວກເຮົາມີຂະບວນການຂະຫນານ, ນີ້ສາມາດເກີດຂຶ້ນໄດ້.

ແລະໃນປັດຈຸບັນພວກເຮົາຈະຕິດຕັ້ງສອງ deadlocks. ພວກເຮົາຈະໃສ່ 50 ແລະ 80. ໃນແຖວທໍາອິດ, ຂ້ອຍຈະປັບປຸງຈາກ 50 ຫາ 50. ຂ້ອຍຈະໄດ້ຮັບເລກທຸລະກໍາ 710.

ແລະຫຼັງຈາກນັ້ນຂ້ອຍຈະປ່ຽນ 80 ຫາ 81, ແລະ 50 ຫາ 51.

ແລະນີ້ແມ່ນສິ່ງທີ່ມັນຈະມີລັກສະນະ. ແລະດັ່ງນັ້ນ 710 ມີແຖວທີ່ຖືກບລັອກ, ແລະ 711 ແມ່ນລໍຖ້າການຢືນຢັນ. ພວກເຮົາເຫັນສິ່ງນີ້ເມື່ອພວກເຮົາປັບປຸງ. 710 ເປັນເຈົ້າຂອງຊຸດຂອງພວກເຮົາ. ແລະ 711 ລໍຖ້າ 710 ເພື່ອເຮັດທຸລະກໍາສໍາເລັດ.

ແລະ​ມັນ​ຍັງ​ເວົ້າ​ວ່າ​ໃນ​ແຖວ​ໃດ​ການ​ຢຸດ​ເຊົາ​ການ​ເກີດ​ຂຶ້ນ​. ແລະນີ້ແມ່ນບ່ອນທີ່ມັນເລີ່ມແປກ.

ໃນປັດຈຸບັນພວກເຮົາກໍາລັງປັບປຸງ 80 ເປັນ 80.

ແລະນີ້ແມ່ນບ່ອນທີ່ deadlocks ເລີ່ມຕົ້ນ. 710 ແມ່ນລໍຖ້າຄໍາຕອບຈາກ 711, ແລະ 711 ແມ່ນລໍຖ້າ 710. ແລະນີ້ຈະບໍ່ສິ້ນສຸດດີ. ແລະບໍ່ມີທາງອອກຈາກນີ້. ແລະພວກເຂົາຈະຄາດຫວັງວ່າການຕອບໂຕ້ຈາກກັນແລະກັນ.

ແລະມັນພຽງແຕ່ຈະເລີ່ມຕົ້ນທີ່ຈະຊັກຊ້າທຸກສິ່ງທຸກຢ່າງ. ແລະພວກເຮົາບໍ່ຕ້ອງການນັ້ນ.

ແລະ Postgres ມີວິທີທີ່ຈະສັງເກດເຫັນເມື່ອສິ່ງນີ້ເກີດຂື້ນ. ແລະໃນເວລາທີ່ມັນເກີດຂຶ້ນ, ທ່ານໄດ້ຮັບຄວາມຜິດພາດນີ້. ແລະຈາກນີ້ມັນເປັນທີ່ຊັດເຈນວ່າຂະບວນການດັ່ງກ່າວແລະດັ່ງກ່າວກໍາລັງລໍຖ້າ SHARE LOCK ຈາກຂະບວນການອື່ນ, i.e., ເຊິ່ງຖືກສະກັດໂດຍຂະບວນການ 711. ແລະຂະບວນການນັ້ນແມ່ນລໍຖ້າໃຫ້ SHARE LOCK ຈະຖືກມອບໃຫ້ຢູ່ໃນລະຫັດທຸລະກໍາດັ່ງກ່າວ ແລະຖືກບລັອກໂດຍຂະບວນການດັ່ງກ່າວ. ເພາະສະນັ້ນ, ສະຖານະການຢຸດຊະງັກຢູ່ທີ່ນີ້.

ມີການປິດກັ້ນສາມທາງບໍ? ມັນ​ເປັນ​ໄປ​ໄດ້​ບໍ່? ແມ່ນແລ້ວ.

ພວກເຮົາໃສ່ຕົວເລກເຫຼົ່ານີ້ເຂົ້າໄປໃນຕາຕະລາງ. ພວກເຮົາປ່ຽນ 40 ຫາ 40, ພວກເຮົາເຮັດການຂັດຂວາງ.

ພວກເຮົາປ່ຽນ 60 ຫາ 61, 80 ຫາ 81.

ແລະຫຼັງຈາກນັ້ນພວກເຮົາປ່ຽນ 80 ແລະຫຼັງຈາກນັ້ນ boom!

ແລະ 714 ໃນປັດຈຸບັນລໍຖ້າ 715. 716th ແມ່ນລໍຖ້າ 715th. ແລະບໍ່ມີຫຍັງສາມາດເຮັດໄດ້ກ່ຽວກັບມັນ.

ຢູ່ທີ່ນີ້ບໍ່ມີສອງຄົນອີກແລ້ວ, ຢູ່ທີ່ນີ້ມີສາມຄົນແລ້ວ. ຂ້ອຍຕ້ອງການບາງສິ່ງບາງຢ່າງຈາກເຈົ້າ, ຄົນນີ້ຕ້ອງການບາງສິ່ງບາງຢ່າງຈາກບຸກຄົນທີສາມ, ແລະບຸກຄົນທີ່ສາມຕ້ອງການບາງສິ່ງບາງຢ່າງຈາກຂ້ອຍ. ແລະພວກເຮົາສິ້ນສຸດການລໍຖ້າສາມທາງເພາະວ່າພວກເຮົາທັງຫມົດລໍຖ້າໃຫ້ຄົນອື່ນເຮັດສໍາເລັດສິ່ງທີ່ເຂົາເຈົ້າຕ້ອງການ.

ແລະ Postgres ຮູ້ວ່າມັນເກີດຂື້ນໃນແຖວໃດ. ແລະດັ່ງນັ້ນມັນຈະໃຫ້ທ່ານຂໍ້ຄວາມຕໍ່ໄປນີ້, ເຊິ່ງສະແດງໃຫ້ເຫັນວ່າທ່ານມີບັນຫາທີ່ສາມ inputs ຂັດຂວາງກັນແລະກັນ. ແລະບໍ່ມີຂໍ້ຈໍາກັດຢູ່ທີ່ນີ້. ນີ້ອາດຈະເປັນກໍລະນີທີ່ 20 ລາຍການຂັດຂວາງກັນແລະກັນ.

ບັນຫາຕໍ່ໄປແມ່ນ serializable.

ຖ້າ lock serializable ພິເສດ.

ແລະພວກເຮົາກັບຄືນໄປຫາ 719. ຜົນຜະລິດຂອງມັນແມ່ນຂ້ອນຂ້າງປົກກະຕິ.

ແລະທ່ານສາມາດຄລິກເພື່ອເຮັດໃຫ້ທຸລະກໍາຈາກ serializable.

ແລະທ່ານຮັບຮູ້ວ່າໃນປັດຈຸບັນທ່ານມີປະເພດທີ່ແຕກຕ່າງກັນຂອງ SA lock - ມັນຫມາຍຄວາມວ່າ serializable.

ແລະດັ່ງນັ້ນພວກເຮົາມີປະເພດໃຫມ່ຂອງ lock ເອີ້ນວ່າ SARieadLock, ເຊິ່ງເປັນ lock serial ແລະອະນຸຍາດໃຫ້ທ່ານສາມາດເຂົ້າໄປໃນ serials.

ແລະທ່ານສາມາດໃສ່ດັດຊະນີທີ່ເປັນເອກະລັກ.

ໃນຕາຕະລາງນີ້ພວກເຮົາມີດັດຊະນີທີ່ເປັນເອກະລັກ.

ສະນັ້ນຖ້າຂ້ອຍໃສ່ເລກ 2 ຢູ່ທີ່ນີ້, ຂ້ອຍມີ 2. ແຕ່ຢູ່ເທິງສຸດ, ຂ້ອຍໃສ່ອີກ 2 ໂຕ. ແລະເຈົ້າສາມາດເຫັນໄດ້ວ່າ 721 ມີ lock ສະເພາະ. ແຕ່ໃນປັດຈຸບັນ 722 ກໍາລັງລໍຖ້າ 721 ສໍາເລັດການປະຕິບັດງານຂອງມັນເພາະວ່າມັນບໍ່ສາມາດໃສ່ 2 ຈົນກ່ວາມັນຮູ້ວ່າຈະເກີດຫຍັງຂຶ້ນກັບ 721.

ແລະຖ້າພວກເຮົາເຮັດທຸລະກໍາຍ່ອຍ.

ທີ່ນີ້ພວກເຮົາມີ 723.

ແລະຖ້າພວກເຮົາບັນທຶກຈຸດແລະຫຼັງຈາກນັ້ນປັບປຸງມັນ, ຫຼັງຈາກນັ້ນພວກເຮົາໄດ້ຮັບ ID ການເຮັດທຸລະກໍາໃຫມ່. ນີ້ແມ່ນຮູບແບບອື່ນຂອງພຶດຕິກໍາທີ່ເຈົ້າຕ້ອງລະວັງ. ຖ້າພວກເຮົາສົ່ງຄືນອັນນີ້, ID ການເຮັດທຸລະກໍາຈະຫາຍໄປ. 724 ກໍາລັງອອກໄປ. ແຕ່ດຽວນີ້ພວກເຮົາມີ 725.

ສະນັ້ນຂ້ອຍພະຍາຍາມເຮັດຫຍັງຢູ່ທີ່ນີ້? ຂ້າພະເຈົ້າພະຍາຍາມສະແດງໃຫ້ທ່ານເຫັນຕົວຢ່າງຂອງ locks ຜິດປົກກະຕິທີ່ທ່ານອາດຈະພົບເຫັນ: ບໍ່ວ່າຈະເປັນ locks serializable ຫຼື SAVEPOINT, ເຫຼົ່ານີ້ແມ່ນປະເພດທີ່ແຕກຕ່າງກັນຂອງ locks ທີ່ຈະປາກົດຢູ່ໃນຕາຕະລາງ lock ໄດ້.

ນີ້ແມ່ນການສ້າງ locks explicit (explicit), ເຊິ່ງມີ pg_advisory_lock.

ແລະທ່ານເຫັນວ່າປະເພດຂອງການສະກັດຖືກລະບຸໄວ້ເປັນຄໍາແນະນໍາ. ແລະໃນທີ່ນີ້ມັນເວົ້າວ່າ "ຄໍາແນະນໍາ" ເປັນສີແດງ. ແລະທ່ານພ້ອມກັນສາມາດປິດກັ້ນແບບນີ້ດ້ວຍ pg_advisory_unlock.

ແລະສະຫຼຸບ, ຂ້າພະເຈົ້າຢາກຈະສະແດງໃຫ້ທ່ານເຫັນສິ່ງຫນຶ່ງທີ່ຫນ້າຕື່ນເຕັ້ນ. ຂ້ອຍຈະສ້າງມຸມເບິ່ງອື່ນ. ແຕ່ຂ້ອຍຈະເຂົ້າຮ່ວມຕາຕະລາງ pg_locks ກັບຕາຕະລາງ pg_stat_activity. ແລະເປັນຫຍັງຂ້ອຍຈຶ່ງຢາກເຮັດອັນນີ້? ເນື່ອງຈາກວ່ານີ້ຈະຊ່ວຍໃຫ້ຂ້າພະເຈົ້າເບິ່ງແລະເບິ່ງກອງປະຊຸມປະຈຸບັນທັງຫມົດແລະເບິ່ງສິ່ງທີ່ປະເພດຂອງການລັອກທີ່ເຂົາເຈົ້າລໍຖ້າ. ແລະນີ້ແມ່ນຫນ້າສົນໃຈຫຼາຍເມື່ອພວກເຮົາເອົາຕາຕະລາງລັອກແລະຕາຕະລາງສອບຖາມ.

ແລະໃນທີ່ນີ້ພວກເຮົາສ້າງ pg_stat_view.

ແລະພວກເຮົາປັບປຸງແຖວໂດຍຫນຶ່ງ. ແລະໃນທີ່ນີ້ພວກເຮົາເຫັນ 724. ແລະຫຼັງຈາກນັ້ນພວກເຮົາປັບປຸງແຖວຂອງພວກເຮົາເປັນສາມ. ແລະເຈົ້າເຫັນຫຍັງຢູ່ທີ່ນີ້? ເຫຼົ່ານີ້ແມ່ນຄໍາຮ້ອງຂໍ, i. e. ທ່ານຈະເຫັນບັນຊີລາຍຊື່ທັງຫມົດຂອງຄໍາຮ້ອງຂໍທີ່ລະບຸໄວ້ໃນຖັນຊ້າຍ. ແລະຫຼັງຈາກນັ້ນຢູ່ເບື້ອງຂວາທ່ານສາມາດເບິ່ງການຂັດຂວາງແລະສິ່ງທີ່ພວກເຂົາສ້າງ. ແລະມັນສາມາດເຫັນໄດ້ຊັດເຈນກວ່າສໍາລັບທ່ານເພື່ອວ່າທ່ານຈະບໍ່ຕ້ອງກັບຄືນໄປຫາແຕ່ລະກອງປະຊຸມທຸກໆຄັ້ງແລະເບິ່ງວ່າທ່ານຈໍາເປັນຕ້ອງເຂົ້າຮ່ວມມັນຫຼືບໍ່. ພວກເຂົາເຈົ້າເຮັດມັນສໍາລັບພວກເຮົາ.

ຄຸນນະສົມບັດອີກອັນຫນຶ່ງທີ່ເປັນປະໂຫຍດຫຼາຍແມ່ນ pg_blocking_pids. ທ່ານອາດຈະບໍ່ເຄີຍໄດ້ຍິນກ່ຽວກັບນາງ. ລາວ​ກໍາ​ລັງ​ເຮັດ​ຫຍັງ? ມັນອະນຸຍາດໃຫ້ພວກເຮົາບອກໄດ້ວ່າສໍາລັບກອງປະຊຸມນີ້ 11740 ID ຂະບວນການສະເພາະໃດທີ່ມັນລໍຖ້າ. ແລະທ່ານສາມາດເຫັນໄດ້ວ່າ 11740 ແມ່ນລໍຖ້າ 724. ແລະ 724 ແມ່ນຢູ່ເທິງສຸດ. ແລະ 11306 ແມ່ນ ID ຂະບວນການຂອງທ່ານ. ໂດຍພື້ນຖານແລ້ວ, ຟັງຊັນນີ້ຜ່ານຕາຕະລາງລັອກຂອງທ່ານ. ແລະຂ້ອຍຮູ້ວ່າມັນສັບສົນເລັກນ້ອຍ, ແຕ່ເຈົ້າສາມາດເຂົ້າໃຈມັນ. ໂດຍພື້ນຖານແລ້ວ, ຟັງຊັນນີ້ຈະຜ່ານຕາຕະລາງລັອກນີ້ແລະພະຍາຍາມຊອກຫາບ່ອນທີ່ ID ຂະບວນການນີ້ຖືກມອບໃຫ້ລັອກທີ່ມັນລໍຖ້າຢູ່. ແລະມັນຍັງພະຍາຍາມຄິດອອກວ່າຂະບວນການໃດ ID ຂະບວນການທີ່ລໍຖ້າການລັອກມີ. ດັ່ງນັ້ນທ່ານສາມາດດໍາເນີນການຟັງຊັນນີ້ pg_blocking_pids.

ແລະນີ້ສາມາດເປັນປະໂຫຍດຫຼາຍ. ພວກເຮົາພຽງແຕ່ເພີ່ມນີ້ໃນຮຸ່ນ 9.6, ດັ່ງນັ້ນຄຸນສົມບັດນີ້ມີພຽງແຕ່ 5 ປີເທົ່ານັ້ນ, ແຕ່ມັນເປັນປະໂຫຍດຫຼາຍ. ແລະດຽວກັນໃຊ້ກັບການຮ້ອງຂໍທີສອງ. ມັນສະແດງໃຫ້ເຫັນສິ່ງທີ່ພວກເຮົາຕ້ອງການເບິ່ງ.

ນີ້ແມ່ນສິ່ງທີ່ຂ້ອຍຢາກເວົ້າກັບເຈົ້າ. ແລະຕາມທີ່ຂ້ອຍຄາດໄວ້, ພວກເຮົາໃຊ້ເວລາທັງໝົດຂອງພວກເຮົາ ເພາະວ່າມີສະໄລ້ຫຼາຍ. ແລະສະໄລ້ແມ່ນສາມາດໃຊ້ໄດ້ສໍາລັບການດາວໂຫຼດ. ຂ້າພະເຈົ້າຢາກຂໍຂອບໃຈທ່ານສໍາລັບການຢູ່ທີ່ນີ້. ຂ້ອຍແນ່ໃຈວ່າເຈົ້າຈະເພີດເພີນກັບສ່ວນທີ່ເຫຼືອຂອງກອງປະຊຸມ, ຂອບໃຈຫຼາຍໆ!

ຄໍາຖາມ:

ຕົວຢ່າງ, ຖ້າຂ້ອຍພະຍາຍາມປັບປຸງແຖວ, ແລະກອງປະຊຸມທີສອງແມ່ນພະຍາຍາມລຶບຕາຕະລາງທັງຫມົດ. ເທົ່າທີ່ຂ້າພະເຈົ້າເຂົ້າໃຈ, ຄວນຈະມີບາງສິ່ງບາງຢ່າງເຊັ່ນ: ການລັອກຄວາມຕັ້ງໃຈ. ມີສິ່ງດັ່ງກ່າວຢູ່ໃນ Postgres ບໍ?

ໃຫ້ກັບຄືນສູ່ຈຸດເລີ່ມຕົ້ນ. ທ່ານອາດຈະຈື່ໄວ້ວ່າເມື່ອທ່ານເຮັດຫຍັງ, ຕົວຢ່າງເຊັ່ນເມື່ອທ່ານເຮັດ SELECT, ພວກເຮົາອອກ AccessShareLock. ແລະນີ້ປ້ອງກັນບໍ່ໃຫ້ຕາຕະລາງຖືກຫຼຸດລົງ. ດັ່ງນັ້ນ, ສໍາລັບຕົວຢ່າງ, ທ່ານຕ້ອງການປັບປຸງແຖວໃນຕາຕະລາງຫຼືລຶບແຖວ, ຫຼັງຈາກນັ້ນຜູ້ໃດຜູ້ຫນຶ່ງບໍ່ສາມາດລຶບຕາຕະລາງທັງຫມົດໃນເວລາດຽວກັນເພາະວ່າທ່ານກໍາລັງຖື AccessShareLock ນີ້ຢູ່ໃນຕາຕະລາງທັງຫມົດແລະຫຼາຍກວ່າແຖວ. ແລະເມື່ອທ່ານເຮັດແລ້ວ, ພວກເຂົາສາມາດລຶບມັນໄດ້. ແຕ່ໃນຂະນະທີ່ທ່ານປ່ຽນບາງສິ່ງບາງຢ່າງໂດຍກົງຢູ່ທີ່ນັ້ນ, ພວກເຂົາຈະບໍ່ສາມາດເຮັດໄດ້.

ໃຫ້ເຮັດມັນອີກຄັ້ງ. ໃຫ້ກ້າວໄປສູ່ຕົວຢ່າງການລຶບ. ແລະທ່ານເຫັນວ່າມີ lock ສະເພາະຢູ່ໃນແຖວຂ້າງເທິງຕາຕະລາງທັງຫມົດ.

ນີ້ຈະມີລັກສະນະເປັນ lock exclusive, ສິດ?

ແມ່ນແລ້ວ, ເບິ່ງຄືວ່າມັນ. ຂ້ອຍເຂົ້າໃຈສິ່ງທີ່ເຈົ້າເວົ້າກ່ຽວກັບ. ເຈົ້າເວົ້າວ່າຖ້າຂ້ອຍເຮັດ SELECT ແລ້ວຂ້ອຍມີ ShareExclusive ແລະຫຼັງຈາກນັ້ນຂ້ອຍເຮັດໃຫ້ມັນເປັນ Row Exclusive, ມັນກາຍເປັນບັນຫາບໍ? ແຕ່ເປັນເລື່ອງແປກທີ່ມັນບໍ່ເປັນບັນຫາ. ນີ້ເບິ່ງຄືວ່າເປັນການເພີ່ມລະດັບການລັອກ, ແຕ່ສໍາຄັນຂ້ອຍມີ lock ທີ່ປ້ອງກັນການລຶບ. ແລະໃນປັດຈຸບັນ, ໃນເວລາທີ່ຂ້າພະເຈົ້າເຮັດໃຫ້ການລັອກນີ້ມີອໍານາດຫຼາຍ, ມັນຍັງປ້ອງກັນການລຶບ. ສະນັ້ນມັນບໍ່ຄືກັບວ່າຂ້ອຍຈະຂຶ້ນໄປ. ນັ້ນແມ່ນ, ມັນປ້ອງກັນບໍ່ໃຫ້ມັນເກີດຂື້ນໃນເວລາທີ່ມັນຢູ່ໃນລະດັບຕ່ໍາເກີນໄປ, ດັ່ງນັ້ນເມື່ອຂ້ອຍຍົກສູງລະດັບຂອງມັນ, ມັນຍັງປ້ອງກັນບໍ່ໃຫ້ຕາຕະລາງຖືກລຶບ.

ຂ້ອຍເຂົ້າໃຈສິ່ງທີ່ເຈົ້າເວົ້າກ່ຽວກັບ. ບໍ່​ມີ​ກໍ​ລະ​ນີ lock escalation ທີ່​ນີ້​, ບ່ອນ​ທີ່​ທ່ານ​ກໍາ​ລັງ​ພະ​ຍາ​ຍາມ​ທີ່​ຈະ​ໃຫ້​ເຖິງ​ຫນຶ່ງ lock ເພື່ອ​ແນະ​ນໍາ​ຫນຶ່ງ​ທີ່​ເຂັ້ມ​ແຂງ​. ໃນທີ່ນີ້ມັນພຽງແຕ່ເພີ່ມການປ້ອງກັນນີ້ໃນທົ່ວຄະນະ, ດັ່ງນັ້ນມັນບໍ່ໄດ້ເຮັດໃຫ້ເກີດຄວາມຂັດແຍ້ງໃດໆ. ແຕ່ມັນເປັນຄໍາຖາມທີ່ດີ. ຂອບໃຈຫຼາຍໆທີ່ຖາມເລື່ອງນີ້!

ພວກເຮົາຈໍາເປັນຕ້ອງເຮັດແນວໃດເພື່ອຫຼີກເວັ້ນການສະຖານະການຕາຍໃນເວລາທີ່ພວກເຮົາມີກອງປະຊຸມຈໍານວນຫຼາຍ, ຈໍານວນຜູ້ໃຊ້ຈໍານວນຫລາຍ?

Postgres ສັງເກດເຫັນສະຖານະການປິດທ້າຍໂດຍອັດຕະໂນມັດ. ແລະມັນຈະລຶບຫນຶ່ງຂອງເຊດຊັນໂດຍອັດຕະໂນມັດ. ວິທີດຽວທີ່ຈະຫຼີກລ້ຽງການປິດກັ້ນທີ່ຕາຍແລ້ວແມ່ນການຂັດຂວາງຄົນໃນຄໍາສັ່ງດຽວກັນ. ດັ່ງນັ້ນ, ໃນເວລາທີ່ທ່ານເບິ່ງຄໍາຮ້ອງສະຫມັກຂອງທ່ານ, ມັກຈະເປັນເຫດຜົນສໍາລັບການ deadlocks ... ໃຫ້ຈິນຕະນາການວ່າຂ້າພະເຈົ້າຕ້ອງການທີ່ຈະສະກັດສອງສິ່ງທີ່ແຕກຕ່າງກັນ. ຄໍາຮ້ອງສະຫມັກຫນຶ່ງລັອກຕາຕະລາງ 1, ແລະຄໍາຮ້ອງສະຫມັກອື່ນ locks 2, ແລະຫຼັງຈາກນັ້ນຕາຕະລາງ 1. ແລະວິທີທີ່ງ່າຍທີ່ສຸດເພື່ອຫຼີກເວັ້ນການ deadlocks ແມ່ນການເບິ່ງຄໍາຮ້ອງສະຫມັກຂອງທ່ານແລະພະຍາຍາມໃຫ້ແນ່ໃຈວ່າການລັອກເກີດຂຶ້ນໃນຄໍາສັ່ງດຽວກັນໃນທົ່ວທຸກຄໍາຮ້ອງສະຫມັກ. ແລະນີ້ປົກກະຕິແລ້ວຈະລົບລ້າງ 80% ຂອງບັນຫາ, ເນື່ອງຈາກວ່າທຸກປະເພດຂອງປະຊາຊົນຂຽນຄໍາຮ້ອງສະຫມັກເຫຼົ່ານີ້. ແລະຖ້າທ່ານຕັນພວກມັນຢູ່ໃນຄໍາສັ່ງດຽວກັນ, ຫຼັງຈາກນັ້ນທ່ານຈະບໍ່ພົບສະຖານະການຢຸດ.

ຂໍ​ຂອບ​ໃຈ​ທ່ານ​ຫຼາຍ​ສໍາ​ລັບ​ການ​ປະ​ຕິ​ບັດ​ຂອງ​ທ່ານ​! ທ່ານໄດ້ເວົ້າກ່ຽວກັບສູນຍາກາດເຕັມແລະ, ຖ້າຂ້ອຍເຂົ້າໃຈຢ່າງຖືກຕ້ອງ, ສູນຍາກາດເຕັມຈະບິດເບືອນຄໍາສັ່ງຂອງບັນທຶກໃນການເກັບຮັກສາແຍກຕ່າງຫາກ, ດັ່ງນັ້ນພວກເຂົາຮັກສາບັນທຶກໃນປະຈຸບັນບໍ່ປ່ຽນແປງ. ເປັນຫຍັງສູນຍາກາດເຕັມຈຶ່ງເອົາການເຂົ້າເຖິງລັອກແບບພິເສດສະເພາະ ແລະເປັນຫຍັງມັນຈຶ່ງຂັດກັບການດຳເນີນການຂຽນ?

ນັ້ນແມ່ນຄໍາຖາມທີ່ດີ. ເຫດຜົນແມ່ນວ່າສູນຍາກາດເຕັມໄປຕາຕະລາງ. ແລະພວກເຮົາເປັນສິ່ງຈໍາເປັນທີ່ຈະສ້າງສະບັບໃຫມ່ຂອງຕາຕະລາງ. ແລະຕາຕະລາງຈະໃຫມ່. ມັນ turns ອອກນີ້ຈະເປັນສະບັບໃຫມ່ຫມົດຂອງຕາຕະລາງ. ແລະບັນຫາແມ່ນວ່າເມື່ອພວກເຮົາເຮັດສິ່ງນີ້, ພວກເຮົາບໍ່ຕ້ອງການໃຫ້ຄົນອ່ານມັນເພາະວ່າພວກເຮົາຕ້ອງການໃຫ້ພວກເຂົາເບິ່ງຕາຕະລາງໃຫມ່. ແລະດັ່ງນັ້ນນີ້ເຊື່ອມຕໍ່ກັບຄໍາຖາມທີ່ຜ່ານມາ. ຖ້າພວກເຮົາສາມາດອ່ານໃນເວລາດຽວກັນ, ພວກເຮົາຈະບໍ່ສາມາດຍ້າຍມັນແລະນໍາຄົນໄປຫາຕາຕະລາງໃຫມ່. ພວກເຮົາຈໍາເປັນຕ້ອງລໍຖ້າໃຫ້ທຸກຄົນອ່ານຕາຕະລາງນີ້ໃຫ້ຈົບ, ແລະດັ່ງນັ້ນມັນເປັນສິ່ງຈໍາເປັນທີ່ຈະເປັນສະຖານະການລັອກ.
ພວກເຮົາພຽງແຕ່ເວົ້າວ່າພວກເຮົາລັອກໃນຕອນເລີ່ມຕົ້ນເພາະວ່າພວກເຮົາຮູ້ວ່າໃນທີ່ສຸດພວກເຮົາຈະຕ້ອງການລັອກສະເພາະເພື່ອຍ້າຍທຸກຄົນໄປຫາສໍາເນົາໃຫມ່. ດັ່ງນັ້ນ, ພວກເຮົາສາມາດແກ້ໄຂບັນຫານີ້ໄດ້. ແລະພວກເຮົາເຮັດມັນດ້ວຍວິທີການດັດສະນີພ້ອມໆກັນ. ແຕ່ນີ້ແມ່ນມີຄວາມຫຍຸ້ງຍາກຫຼາຍທີ່ຈະເຮັດ. ແລະນີ້ຫຼາຍກ່ຽວຂ້ອງກັບຄໍາຖາມທີ່ຜ່ານມາຂອງທ່ານກ່ຽວກັບ lock exclusive.

ມັນເປັນໄປໄດ້ທີ່ຈະເພີ່ມເວລາລັອກໃສ່ Postgres ບໍ? ຕົວຢ່າງເຊັ່ນໃນ Oracle, ຂ້ອຍສາມາດຂຽນ "ເລືອກເພື່ອອັບເດດ" ແລະລໍຖ້າ 50 ວິນາທີກ່ອນທີ່ຈະອັບເດດ. ມັນເປັນການດີສໍາລັບຄໍາຮ້ອງສະຫມັກ. ແຕ່ໃນ Postgres, ຂ້ອຍຈໍາເປັນຕ້ອງເຮັດມັນທັນທີແລະບໍ່ລໍຖ້າເລີຍ, ຫຼືລໍຖ້າຈົນກ່ວາບາງເວລາ.

ແມ່ນແລ້ວ, ທ່ານສາມາດເລືອກເວລາໝົດເວລາໃນລັອກຂອງເຈົ້າ, ໃນລັອກຂອງເຈົ້າ. ນອກນັ້ນທ່ານຍັງສາມາດອອກຄໍາສັ່ງທີ່ບໍ່ມີວິທີການ, ເຊິ່ງຈະ ... ຖ້າຫາກວ່າທ່ານບໍ່ສາມາດໄດ້ຮັບ lock ໄດ້ທັນທີ. ດັ່ງນັ້ນ, ບໍ່ວ່າຈະເປັນການຫມົດເວລາລັອກຫຼືສິ່ງອື່ນທີ່ຈະຊ່ວຍໃຫ້ທ່ານເຮັດສິ່ງນີ້. ນີ້ບໍ່ໄດ້ເຮັດຢູ່ໃນລະດັບ syntactic. ນີ້ແມ່ນເຮັດເປັນຕົວແປໃນເຄື່ອງແມ່ຂ່າຍ. ບາງຄັ້ງອັນນີ້ບໍ່ສາມາດໃຊ້ໄດ້.

ເຈົ້າສາມາດເປີດ slide 75 ໄດ້ບໍ?

ແມ່ນແລ້ວ.

ແລະຄໍາຖາມຂອງຂ້ອຍແມ່ນຕໍ່ໄປນີ້. ເປັນຫຍັງຂະບວນການອັບເດດທັງສອງຄາດວ່າຈະມີ 703?

ແລະນີ້ແມ່ນຄໍາຖາມທີ່ຍິ່ງໃຫຍ່. ຂ້ອຍບໍ່ເຂົ້າໃຈ, ໂດຍວິທີທາງການ, ເປັນຫຍັງ Postgres ເຮັດແບບນີ້. ແຕ່ເມື່ອ 703 ຖືກສ້າງຂື້ນ, ຄາດວ່າຈະມີ 702. ແລະເມື່ອ 704 ແລະ 705 ປາກົດ, ມັນເບິ່ງຄືວ່າພວກເຂົາບໍ່ຮູ້ວ່າພວກເຂົາຄາດຫວັງຫຍັງເພາະວ່າບໍ່ມີຫຍັງຢູ່ທີ່ນັ້ນ. ແລະ Postgres ເຮັດແບບນີ້: ເມື່ອທ່ານບໍ່ສາມາດລັອກໄດ້, ມັນຂຽນວ່າ "ຈຸດໃດໃນການປຸງແຕ່ງເຈົ້າ?", ເພາະວ່າເຈົ້າກໍາລັງລໍຖ້າໃຜຜູ້ຫນຶ່ງຢູ່ແລ້ວ. ສະນັ້ນພວກເຮົາຈະປ່ອຍໃຫ້ມັນຢູ່ໃນອາກາດ, ມັນຈະບໍ່ອັບເດດມັນເລີຍ. ແຕ່ສິ່ງທີ່ເກີດຂຶ້ນທີ່ນີ້? ທັນທີທີ່ 702 ສໍາເລັດຂະບວນການແລະ 703 ໄດ້ຮັບ lock ຂອງຕົນ, ລະບົບກັບຄືນມາ. ແລະນາງເວົ້າວ່າຕອນນີ້ພວກເຮົາມີສອງຄົນທີ່ລໍຖ້າ. ແລະຫຼັງຈາກນັ້ນໃຫ້ພວກເຮົາປັບປຸງໃຫ້ເຂົາເຈົ້າຮ່ວມກັນ. ແລະໃຫ້ພວກເຮົາຊີ້ໃຫ້ເຫັນວ່າທັງສອງຄາດວ່າຈະ.

ຂ້ອຍບໍ່ຮູ້ວ່າເປັນຫຍັງ Postgres ເຮັດແບບນີ້. ແຕ່ມີບັນຫາທີ່ເອີ້ນວ່າ f…. ມັນເບິ່ງຄືວ່າຂ້ອຍວ່ານີ້ບໍ່ແມ່ນຄໍາສັບໃນພາສາລັດເຊຍ. ນີ້ແມ່ນເວລາທີ່ທຸກຄົນລໍຖ້າ Castle ຫນຶ່ງ, ເຖິງແມ່ນວ່າຈະມີເຈົ້າຫນ້າທີ່ 20 ທີ່ລໍຖ້າ Castle. ແລະທັນທີທັນໃດພວກເຂົາທັງຫມົດຕື່ນນອນໃນເວລາດຽວກັນ. ແລະທຸກຄົນເລີ່ມພະຍາຍາມໂຕ້ຕອບ. ແຕ່ລະບົບເຮັດໃຫ້ມັນເພື່ອໃຫ້ທຸກຄົນລໍຖ້າ 703. ເພາະວ່າພວກເຂົາລໍຖ້າທັງຫມົດ, ແລະພວກເຮົາຈະສາຍໃຫ້ພວກເຂົາທັງຫມົດໃນທັນທີ. ແລະຖ້າຄໍາຮ້ອງຂໍໃຫມ່ອື່ນໆທີ່ປະກົດວ່າຖືກສ້າງຂື້ນຫຼັງຈາກນັ້ນ, ຕົວຢ່າງ 707, ມັນຈະມີຄວາມຫວ່າງເປົ່າອີກເທື່ອຫນຶ່ງ.

ແລະມັນເບິ່ງຄືວ່າຂ້ອຍໄດ້ເຮັດດັ່ງນັ້ນພວກເຮົາສາມາດເວົ້າໄດ້ວ່າໃນຂັ້ນຕອນນີ້ 702 ແມ່ນລໍຖ້າ 703, ແລະທຸກຄົນທີ່ເຂົ້າມາຫຼັງຈາກນັ້ນຈະບໍ່ມີການເຂົ້າມາໃນພາກສະຫນາມນີ້. ແຕ່ທັນທີທີ່ຜູ້ຮັບໃຊ້ຄົນທໍາອິດອອກໄປ, ທຸກຄົນທີ່ລໍຖ້າຢູ່ກ່ອນການອັບເດດຈະໄດ້ຮັບໂທເຄັນດຽວກັນ. ແລະດັ່ງນັ້ນຂ້າພະເຈົ້າຄິດວ່ານີ້ແມ່ນເຮັດໄດ້ເພື່ອໃຫ້ພວກເຮົາສາມາດປຸງແຕ່ງຕາມລໍາດັບເພື່ອໃຫ້ພວກມັນຖືກສັ່ງຢ່າງຖືກຕ້ອງ.

ຂ້າ​ພະ​ເຈົ້າ​ສະ​ເຫມີ​ໄປ​ເບິ່ງ​ຢູ່​ໃນ​ນີ້​ເປັນ​ປະ​ກົດ​ການ​ແປກ​ຫຼາຍ​. ເນື່ອງຈາກວ່າໃນທີ່ນີ້, ສໍາລັບການຍົກຕົວຢ່າງ, ພວກເຮົາບໍ່ໄດ້ບອກພວກເຂົາທັງຫມົດ. ແຕ່ມັນເບິ່ງຄືວ່າຂ້ອຍທຸກຄັ້ງທີ່ພວກເຮົາໃຫ້ລັອກໃຫມ່, ພວກເຮົາເບິ່ງທັງຫມົດຜູ້ທີ່ຢູ່ໃນຂະບວນການລໍຖ້າ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາຈັດແຖວໃຫ້ເຂົາເຈົ້າທັງຫມົດ. ແລະຫຼັງຈາກນັ້ນອັນໃຫມ່ທີ່ເຂົ້າມາພຽງແຕ່ໄດ້ຮັບເຂົ້າໄປໃນແຖວໃນເວລາທີ່ຄົນຕໍ່ໄປສໍາເລັດການດໍາເນີນການ. ຄໍາຖາມທີ່ດີຫຼາຍ. ຂອບໃຈຫຼາຍໆສຳລັບຄຳຖາມຂອງເຈົ້າ!

ມັນເບິ່ງຄືວ່າຂ້ອຍມີເຫດຜົນຫຼາຍເມື່ອ 705 ຄາດຫວັງວ່າ 704.

ແຕ່ບັນຫານີ້ແມ່ນຕໍ່ໄປນີ້. ໃນທາງດ້ານວິຊາການ, ທ່ານສາມາດປຸກຫນຶ່ງຫຼືອື່ນ. ແລະດັ່ງນັ້ນພວກເຮົາຈະປຸກຫນຶ່ງຫຼືອື່ນໆ. ແຕ່ສິ່ງທີ່ເກີດຂື້ນໃນລະບົບ? ທ່ານສາມາດເບິ່ງວິທີການ 703 ຢູ່ເທິງສຸດໄດ້ບລັອກ ID ການເຮັດທຸລະກໍາຂອງຕົນເອງ. ນີ້ແມ່ນວິທີທີ່ Postgres ເຮັດວຽກ. ແລະ 703 ຖືກບລັອກໂດຍ ID ການເຮັດທຸລະກໍາຂອງຕົນເອງ, ດັ່ງນັ້ນຖ້າໃຜຜູ້ຫນຶ່ງຕ້ອງການລໍຖ້າ, ຫຼັງຈາກນັ້ນພວກເຂົາຈະລໍຖ້າ 703. ແລະ, ໂດຍເນື້ອແທ້ແລ້ວ, 703 ສໍາເລັດ. ແລະພຽງແຕ່ຫຼັງຈາກສໍາເລັດຂອງມັນບໍ່ຫນຶ່ງຂອງຂະບວນການປຸກ. ແລະພວກເຮົາບໍ່ຮູ້ວ່າຂະບວນການນີ້ຈະເປັນແນວໃດ. ຫຼັງຈາກນັ້ນ, ພວກເຮົາປຸງແຕ່ງທຸກສິ່ງທຸກຢ່າງຄ່ອຍໆ. ແຕ່ມັນບໍ່ຊັດເຈນວ່າຂະບວນການໃດຖືກປຸກກ່ອນ, ເພາະວ່າມັນອາດຈະເປັນຂະບວນການໃດໆ. ໂດຍພື້ນຖານແລ້ວ, ພວກເຮົາມີຕົວກໍານົດເວລາທີ່ກ່າວວ່າພວກເຮົາສາມາດປຸກຂະບວນການເຫຼົ່ານີ້ໄດ້. ພວກເຮົາພຽງແຕ່ເລືອກເອົາຫນຶ່ງໂດຍສຸ່ມ. ສະນັ້ນພວກເຂົາທັງສອງຈໍາເປັນຕ້ອງໄດ້ສັງເກດເຫັນເພາະວ່າພວກເຮົາສາມາດປຸກພວກເຂົາທັງສອງ.

ແລະບັນຫາແມ່ນວ່າພວກເຮົາມີ CP-infinity. ແລະເພາະສະນັ້ນ, ມັນເປັນໄປໄດ້ຂ້ອນຂ້າງທີ່ພວກເຮົາສາມາດຕື່ນຂຶ້ນໃນພາຍຫຼັງ. ແລະຖ້າ, ຕົວຢ່າງ, ພວກເຮົາປຸກຄົນຕໍ່ມາ, ພວກເຮົາຈະລໍຖ້າຜູ້ທີ່ພຽງແຕ່ໄດ້ຮັບຕັນ, ດັ່ງນັ້ນພວກເຮົາບໍ່ໄດ້ກໍານົດວ່າໃຜແນ່ນອນຈະຖືກປຸກກ່ອນ. ພວກເຮົາພຽງແຕ່ສ້າງສະຖານະການດັ່ງກ່າວ, ແລະລະບົບຈະປຸກໃຫ້ເຂົາເຈົ້າໃນຄໍາສັ່ງ Random.

ມີ ບົດຄວາມກ່ຽວກັບການລັອກໂດຍ Egor Rogov. ເບິ່ງ, ພວກເຂົາຍັງຫນ້າສົນໃຈແລະເປັນປະໂຫຍດ. ຫົວຂໍ້, ແນ່ນອນ, ແມ່ນສັບສົນຫຼາຍ. ຂອບໃຈຫຼາຍໆ, Bruce!

ແຫຼ່ງຂໍ້ມູນ: www.habr.com