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

On Mon, 9 Dec 2024 at 23:13, Noah Misch <noah(at)leadboat(dot)com> wrote:
> 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.

Yes, I just copied LockTuple from AlterDatabaseOwner, but it turns out
that the problem is more complex than I first believed.

PFA v2. I tried to follow your suggestion.
The get_catalog_object_by_oid_extended method, which I added to v2,
acts similarly to get_catalog_object_by_oid but locks the tuple being
searched.
Do you think this design looks good?

> A fix for $SUBJECT also warrants a test in database.sql.

Sure. I added one test case to dependency.sql (for DATABASE ownership
change), do we need more (other catalog classes)?

--
Best regards,
Kirill Reshke