Re: [BUG] orphaned function

"Drouvot, Bertrand" <bdrouvot(at)amazon(dot)com> writes:
> here is a scenario that produces an orphaned function (means it does not
> belong to any namespace):
> [ drop schema before committing function creation ]

Hm. Historically we've not been too fussed about preventing such race
conditions, and I wonder just how far is sane to take it. Should we
acquire lock on the function's argument/result data types? Its language?

Given the precedent of RangeVarGetAndCheckCreationNamespace, I'm
willing to accept this patch's goals as stated. But it feels like
we need some clearer shared understanding of which things we are
willing to bother with preventing races for, and which we aren't.

> Please find attached a patch that adds a LockDatabaseObject() call in
> QualifiedNameGetCreationNamespace() to prevent such orphaned situations.

I don't think that actually succeeds in preventing the race, it'll
just delay your process till the deletion is committed. But you
already have the namespaceId. Note the complex retry logic in
RangeVarGetAndCheckCreationNamespace; without something on the same
order, you're not closing the hole in any meaningful way. Likely
what this patch should do is refactor that function so that its guts
can be used for other object-creation scenarios. (The fact that
this is so far from trivial is one reason I'm not in a hurry to
extend this sort of protection to other dependencies.)

regards, tom lane