From: | PG Bug reporting form <noreply(at)postgresql(dot)org> |
---|---|
To: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Cc: | dafoer_x(at)163(dot)com |
Subject: | BUG #18331: Why is the session lock (DEFAULT_LOCKMETHOD) not automatically released during process exit? |
Date: | 2024-02-05 07:28:53 |
Message-ID: | 18331-b44b290d8d84d690@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
The following bug has been logged on the website:
Bug reference: 18331
Logged by: Why is the session lock (DEFAULT_LOCKMETHOD) not automatically released
during process exit?
Email address: dafoer_x(at)163(dot)com
PostgreSQL version: 16.1
Operating system: centos_x86
Description:
I have some doubts about the implementation of session locks. Can you help
me clarify my questions?
The comment for the function LockRelationIdForSession mentions “It will be
removed when UnlockRelationIdForSession() is called, or if an
ereport(ERROR) occurs, or if the backend exits.”
However, the callback function ShutdownPostgres, which is triggered during
process exit, only cleans up locks of type USER_LOCKMETHOD. Is it possible
to automatically clean up session locks of type DEFAULT_LOCKMETHOD?
What risks or implications would there be if session locks of type
USER_LOCKMETHOD were automatically cleaned up during process exit?
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2024-02-05 09:54:01 | BUG #18332: The conditional lock cannot be granted even if the process holds a stronger lock |
Previous Message | Masahiko Sawada | 2024-02-05 02:12:31 | Re: Potential data loss due to race condition during logical replication slot creation |