Re: executor relation handling
От | David Rowley |
---|---|
Тема | Re: executor relation handling |
Дата | |
Msg-id | CAKJS1f8tj9TLcLdpuff4G4Okmb2njevjnaZ6-Wjdr5bKv8U67Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: executor relation handling (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: executor relation handling
|
Список | pgsql-hackers |
On 1 October 2018 at 06:18, Tom Lane <tgl@sss.pgh.pa.us> wrote: > It occurred to me that it'd be reasonable to insist that the caller > holds a lock *at least as strong* as the one being recorded in the RTE, > and that there's also been discussions about verifying that some lock > is held when something like heap_open(foo, NoLock) is attempted. > So I dusted off the part of 0001 that did that, producing the > attached delta patch. My imagination struggles to think of a case, but perhaps one day in the future we might have a lock manager that coordinates locks on multiple nodes. If so, is there not a risk that one day we might have a lock level greater than AccessExclusiveLock, meaning the following would get broken: + for (slockmode = lockmode + 1; + slockmode <= AccessExclusiveLock; + slockmode++) For index strategies we do: #define BTGreaterStrategyNumber 5 #define BTMaxStrategyNumber 5 So would it not be better to add the following to lockdefs.h? #define MaxLockLevel 8 then use that to terminate the loop. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: