Re: Possible Bug in relation_open
| От | Robert Haas |
|---|---|
| Тема | Re: Possible Bug in relation_open |
| Дата | |
| Msg-id | CA+TgmoZ7ZrktneZ9tuu0SMv7ZCM=Zni1OPQKWmv71Q2ZC97PbA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Possible Bug in relation_open (Pradeep Kumar <spradeepkumar29@gmail.com>) |
| Ответы |
Re: Possible Bug in relation_open
|
| Список | pgsql-hackers |
On Tue, May 21, 2024 at 9:58 AM Pradeep Kumar <spradeepkumar29@gmail.com> wrote: > If the user tries to open the relation in RangeVar and NoLock mode calling table_openrv(relation, NoLock), it will internallycall 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 wechecking 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 Whatif the user tries to open the relation in NoLock mode? and that will definitely cause the assert failure, Suppose theuser who writes some extension and reads some relation oid that is constant, and wants to acquire NoLock?, need some clarificationon this. You need to acquire a lock. Otherwise, the relcache entry could change underneath you while you're accessing it, which would result in PostgreSQL crashing. -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: