Re: WARNING: missing lock on database "postgres" (OID 5) @ TID (0,4)
От | Noah Misch |
---|---|
Тема | Re: WARNING: missing lock on database "postgres" (OID 5) @ TID (0,4) |
Дата | |
Msg-id | 20241209181315.3b.nmisch@google.com обсуждение исходный текст |
Ответ на | WARNING: missing lock on database "postgres" (OID 5) @ TID (0,4) (Alexander Kukushkin <cyberdemn@gmail.com>) |
Список | 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@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.
В списке pgsql-hackers по дате отправления: