On Fri, Jul 21, 2023 at 2:57 PM Gurjeet Singh <gurj...@singh.im> wrote: > > On Thu, Jul 20, 2023 at 11:38 PM Junwang Zhao <zhjw...@gmail.com> wrote: > > > > On Fri, Jul 21, 2023 at 2:26 PM Michael Paquier <mich...@paquier.xyz> wrote: > > > > > > On Fri, Jul 21, 2023 at 02:05:56PM +0800, Junwang Zhao wrote: > > > > I noticed there are some places calling table_open with > > > > RowExclusiveLock but table_close with NoLock, like in function > > > > toast_save_datum. > > > > > > > > Can anybody explain the underlying logic, thanks in advance. > > > > > > This rings a bell. This is a wanted behavior, see commit f99870d and > > > its related thread: > > > https://postgr.es/m/17268-d2fb426e0895a...@postgresql.org > > > > > > > I see this patch, so all the locks held by a transaction will be released > > at the commit phase, right? Can you show me where the logic is located? > > The NoLock is simple a marker that tells the underlying machinery to > not bother releasing any locks. As a matter of fact, you can pass > NoLock in *_open() calls, too, to indicate that you don't want any new > locks, perhaps because the transaction has already taken an > appropriate lock on the object. > > As for lock-releasing codepath at transaction end, see > CommitTransaction() in xact.c, and specifically at the > ResourceOwnerRelease() calls in there. >
Great, thanks for the thorough explanation, will look into the code :) > Best regards, > Gurjeet > http://Gurje.et -- Regards Junwang Zhao
