Possible Bug in relation_open

Поиск
Список
Период
Сортировка
От Pradeep Kumar
Тема Possible Bug in relation_open
Дата
Msg-id CAJ4xhPnTRF09CUAv78gY+jKjbjhK6pobY+n_szMSZnrADtyoNQ@mail.gmail.com
обсуждение исходный текст
Ответы Re: Possible Bug in relation_open  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Hello Hackers,

If the user tries to open the relation in RangeVar and NoLock mode calling table_openrv(relation, NoLock), it will internally call relation_openrv()-->relation_open(). In relation_open() we checking the Assert(lockmode >= NoLock && lockmode < MAX_LOCKMODES); , here we expecting the lockmode is NoLock or greater than that, but in same function again we checking this assert case Assert(lockmode != NoLock || IsBootstrapProcessingMode() || CheckRelationLockedByMe(r, AccessShareLock, true)); , here we are expecting (lockmode != NoLock) , so why are there two cases that contradict?  and What if the user tries to open the relation in NoLock mode? and that will definitely cause the assert failure, Suppose the user who writes some extension and reads some relation oid that is constant, and wants to acquire NoLock?, need some clarification on this.

Thanks & Regards
Pradeep

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: ALTER TABLE SET ACCESS METHOD on partitioned tables
Следующее
От: Sandeep Thakkar
Дата:
Сообщение: Re: zlib detection in Meson on Windows broken?