On Tue, Feb 4, 2025 at 9:24 PM Bertrand Drouvot
<bertranddrouvot...@gmail.com> wrote:
>
> Hi,
>
> On Thu, Jan 02, 2025 at 08:15:13AM +0000, Bertrand Drouvot wrote:
> > rebased (v18 attached).
>
> Thanks to all of you that have discussed this patch during the developer
> meeting
> at FOSDEM PGDay last week [1]. I'm attaching a new version to address Álvaro's
> concern about calling getObjectDescription() in the new
> LockNotPinnedObjectById()
> function. This call was being used to provide a "meaningful" error message but
> we agreed to provide the object OID instead (as anyway the object is dropped).
>
> Note that the OIDs are reported as "errdetail" to ensure the isolation tests
> added in this patch remain stable (output does not depend of the actual OIDs
> values).
>
> A quick sum up about this patch:
>
> A. Locking is done exclusively with LockNotPinnedObject(Oid classid, Oid
> objid)
> so that it's now always clear what object we want to acquire a lock for. It
> means
> that we are not manipulating directly an object address or a list of objects
> address as it was the case when the locking was done "directly" within the
> dependency code.
>
> B. A special case is done for objects that belong to the RelationRelationId
> class.
> For those, we should be in one of the two following cases that would already
> prevent the relation to be dropped:
>
> B1. The relation is already locked (could be an existing relation or a
> relation
> that we are creating).
>
> B2. The relation is protected indirectly (i.e an index protected by a lock on
> its table, a table protected by a lock on a function that depends the
> table...)
>
> To avoid any risks for the RelationRelationId class case, we acquire a lock if
> there is none. That may add unnecessary lock for B2. but that seems worth it.
>
> That's a lot of mechanical changes so that's easy to miss one or to do it
> wrong but:
>
> 1. I did my best to avoid that
> 2. assertions are added in recordMultipleDependencies() to "ensure" the object
> is locked
> 3. even if one case is missing (that is not catched by the assertions because
> the dependency is not covered in the tests, not sure that exists though),
> then it
> just means that we could be in the current state (orphaned dependency), not
> worst
> than that
>
> During the meeting a question has been raised regarding the number of locks
> increase. This has already been discussed in [2] and I think that the outcome
> is that the default max_locks_per_transaction value (64) is probably still
> enough in real life (and even if it is not then it can be increased to satisfy
> the requirements).
>
> [1]: https://2025.fosdempgday.org/devmeeting
> [2]:
> https://www.postgresql.org/message-id/CA%2BTgmoaFPUubBBk52Qp2wkoL7JX7OjhewiK%2B7LSot7%3DrecbzzQ%40mail.gmail.com
>
hi.
I plan to play around with v19.
but i can not build based on it.
related error message:
running bootstrap script ... ok
performing post-bootstrap initialization ... TRAP: failed
Assert("LockHeldByMe(&tag, AccessShareLock, false)"), File:
"../../Desktop/pg_src/src1/postgres/src/backend/catalog/pg_depend.c",
Line: 116, PID: 1118343
/home/jian/postgres/regression1/bin/postgres(ExceptionalCondition+0xf3)[0xe66090]
/home/jian/postgres/regression1/bin/postgres(recordMultipleDependencies+0x17f)[0x6ae34d]
/home/jian/postgres/regression1/bin/postgres(record_object_address_dependencies+0x4e)[0x66b333]
/home/jian/postgres/regression1/bin/postgres(ProcedureCreate+0x2443)[0x6b9ad7]
/home/jian/postgres/regression1/bin/postgres(CreateFunction+0xf91)[0x73a7ef]
/home/jian/postgres/regression1/bin/postgres[0xbcba68]
/home/jian/postgres/regression1/bin/postgres(standard_ProcessUtility+0x170c)[0xbc9fb7]
/home/jian/postgres/regression1/bin/postgres(ProcessUtility+0x184)[0xbc889b]
/home/jian/postgres/regression1/bin/postgres[0xbc6821]
/home/jian/postgres/regression1/bin/postgres[0xbc6bbd]
/home/jian/postgres/regression1/bin/postgres(PortalRun+0x3f4)[0xbc5bda]
/home/jian/postgres/regression1/bin/postgres[0xbbae37]
/home/jian/postgres/regression1/bin/postgres(PostgresMain+0x1110)[0xbc2feb]
/home/jian/postgres/regression1/bin/postgres(PostgresMain+0x0)[0xbc1edb]
/home/jian/postgres/regression1/bin/postgres(main+0x4cf)[0x8e98b1]
/lib/x86_64-linux-gnu/libc.so.6(+0x29d90)[0x71d95a829d90]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x80)[0x71d95a829e40]
/home/jian/postgres/regression1/bin/postgres(_start+0x25)[0x4af1c5]
Aborted (core dumped)
child process exited with exit code 134
