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

On Mon, Dec 09, 2024 at 04:50:16PM +0500, Kirill Reshke wrote:
> On Mon, 9 Dec 2024 at 15:27, Alexander Kukushkin <cyberdemn@gmail.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.

On Tue, 10 Dec 2024 at 10:45, Kirill Reshke <reshkekirill@gmail.com> wrote:

> PFA v2.
Also CF entry https://commitfest.postgresql.org/51/5430/ to get CI feedback.


-- 
Best regards,
Kirill Reshke

On Wed, Dec 11, 2024 at 11:37:49AM +0500, Kirill Reshke wrote:
> PFAv4
> 
> regressdeptestdb1 -> regressiondeptestdb1

The reason I said databases.sql for the test is that CREATE DATABASE is
expensive.  We currently have just one successful CREATE DATABASE in the
src/test/regress suite, and we shouldn't add more that reasonably could
instead harness the existing one.  Would you do it that way?