Re: WARNING: missing lock on database "postgres" (OID 5) @ TID (0,4)

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.

In response to

Responses

Browse pgsql-hackers by date

  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