Re: table_open/table_close with different lock mode
Junwang Zhao <zhjwpku@gmail.com>
From: Junwang Zhao <zhjwpku@gmail.com>
To: Michael Paquier <michael@paquier.xyz>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-07-21T06:38:34Z
Lists: 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
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix corruption of toast indexes with REINDEX CONCURRENTLY
- f99870dd8673 15.0 cited