From: | Noah Misch <noah(at)leadboat(dot)com> |
---|---|
To: | Kirill Reshke <reshkekirill(at)gmail(dot)com> |
Cc: | Alexander Kukushkin <cyberdemn(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: WARNING: missing lock on database "postgres" (OID 5) @ TID (0,4) |
Date: | 2024-12-09 18:13:15 |
Message-ID: | 20241209181315.3b.nmisch@google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 09, 2024 at 04:50:16PM +0500, Kirill Reshke wrote:
> On Mon, 9 Dec 2024 at 15:27, Alexander Kukushkin <cyberdemn(at)gmail(dot)com> wrote:
> > postgres=# reassign owned by test to postgres;
> > WARNING: missing lock on database "postgres" (OID 5) @ TID (0,4)
> > REASSIGN OWNED
Thanks for the report.
> --- a/src/backend/commands/alter.c
> +++ b/src/backend/commands/alter.c
> @@ -991,6 +991,8 @@ AlterObjectOwner_internal(Oid classId, Oid objectId, Oid new_ownerId)
> }
> }
>
> + LockTuple(rel, &oldtup->t_self, InplaceUpdateTupleLock);
> +
> /* Build a modified tuple */
This silences the warning, but it doesn't generally satisfy the locking
protocol at README.tuplock section "Locking to write inplace-updated tables".
The specific problem is that this locks the tuple after copying it from shared
buffers. If getting oldtup from a syscache, use SearchSysCacheLocked1().
Otherwise, lock before systable_endscan() and before any copying, like
AlterDatabaseOwner() does.
A fix for $SUBJECT also warrants a test in database.sql.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-12-09 18:16:52 | Re: Assert failure on running a completed portal again |
Previous Message | Matheus Alcantara | 2024-12-09 18:06:11 | Re: SCRAM pass-through authentication for postgres_fdw |