Re: Possible Bug in relation_open
Robert Haas writes: > On Tue, May 21, 2024 at 9:58 AM Pradeep Kumar > wrote: >> 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. > 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. To clarify: the rule is that it's only allowed to pass NoLock if you know for certain that some suitable lock on that relation is already held by the current query. That's why these conditions are complicated. regards, tom lane
Re: Possible Bug in relation_open
On Tue, May 21, 2024 at 9:58 AM Pradeep Kumar wrote: > 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. 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
Possible Bug in relation_open
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
