Re: table_open/table_close with different lock mode
От | Junwang Zhao |
---|---|
Тема | Re: table_open/table_close with different lock mode |
Дата | |
Msg-id | CAEG8a3+f5E53qMygjxcke+Cd934K486oH_c+jCA2=0mYYHwh4g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: table_open/table_close with different lock mode (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: table_open/table_close with different lock mode
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: