Re: Possible Bug in relation_open - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Possible Bug in relation_open
Date
Msg-id CA+TgmoZ7ZrktneZ9tuu0SMv7ZCM=Zni1OPQKWmv71Q2ZC97PbA@mail.gmail.com
Whole thread Raw
In response to Possible Bug in relation_open  (Pradeep Kumar <spradeepkumar29@gmail.com>)
Responses Re: Possible Bug in relation_open
List 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 by date:

Previous
From: Dave Page
Date:
Subject: Re: zlib detection in Meson on Windows broken?
Next
From: Andres Freund
Date:
Subject: Re: zlib detection in Meson on Windows broken?