| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Jingtang Zhang <mrdrivingduck(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Lock tag of relation extend lock |
| Date: | 2025-10-06 14:18:19 |
| Message-ID: | lmswr7x5nz722a7z36obkkjezl744hqyg2hkee2almpi4skgjh@lmgs6g4iphvx |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2025-10-06 19:39:18 +0800, Jingtang Zhang wrote:
> In a recent debug I found two process conflict on relation extension lock,
> one is holding it for MAIN fork extension, while the other one is trying to
> do FSM extension. It seems that the extension lock is using the logical relid
> of a table as lock tag, but smgrextend is independant among each fork.
>
> LockRelationForExtension is used to lock out concurrent extension to get an
> accurate smgrnblocks (of MAIN fork, mostly) for where to extend the fork from.
> Except for that in bufmgr.c, where the forknum is passed in as parameter,
> so main/fsm/vm extension shares the code.
What workload actually has significant enough extension workload on the VM/FSM
to make this a problem?
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | ls7777 | 2025-10-06 14:31:52 | Re: Patch for migration of the pg_commit_ts directory |
| Previous Message | David Rowley | 2025-10-06 13:59:44 | Re: Eager aggregation, take 3 |