Thread: table_open/table_close with different lock mode
Hey hackers, 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. -- Regards Junwang Zhao
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-d2fb426e0895abd4@postgresql.org The tests added by this commit in src/test/isolation/ will show the difference in terms of the way the toast values get handled with and without the change. -- Michael
Attachment
On Fri, Jul 21, 2023 at 2:26 PM Michael Paquier <michael@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-d2fb426e0895abd4@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 tests added by this commit in src/test/isolation/ will show the > difference in terms of the way the toast values get handled with and > without the change. > -- > Michael -- Regards Junwang Zhao
On Thu, Jul 20, 2023 at 11:38 PM Junwang Zhao <zhjwpku@gmail.com> wrote: > > On Fri, Jul 21, 2023 at 2:26 PM Michael Paquier <michael@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-d2fb426e0895abd4@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
On Fri, Jul 21, 2023 at 2:57 PM Gurjeet Singh <gurjeet@singh.im> wrote: > > On Thu, Jul 20, 2023 at 11:38 PM Junwang Zhao <zhjwpku@gmail.com> wrote: > > > > On Fri, Jul 21, 2023 at 2:26 PM Michael Paquier <michael@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-d2fb426e0895abd4@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