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. Best regards, Gurjeet http://Gurje.et
