On Mon, 9 Dec 2024 at 23:13, Noah Misch <n...@leadboat.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
v2-0001-When-making-dependency-changes-lock-the-tuple-for.patch
Description: Binary data
