On Sat, Sep 08, 2018 at 04:21:34PM -0400, Tom Lane wrote:
> I'm still not very happy about this, mainly because it seems like
> (a) it's papering over just a small fraction of the true problem
Check.
> (b) there's been no discussion about cost-benefit tradeoffs.
Noted. I am not sure how to actually prove how an approach is more
beneficial than another.
> What's it going to cost us in terms of additional locking --- not
> only performance, but the potential for new deadlock cases ---
That's more complicated, the cross-lock test coverage is poor.
Designing tests which show the behavior we'd expect is easy enough,
trying to imagine all deadlock issues is harder. One thing which comes
with deadlocking is usually lock upgrade. We could put more safeguards
to make sure that a given locked object does not get locked more.
> and does this really fix enough real-world problems to be worth it?
Using a dirty snapshots would likely help in most cases if we take a
low-level approach as Andres has suggested. This is invasive though
after spending an hour or so looking at how that would be doable when
fetching the object dependencies. And not back-patchable. The lack of
complains about a rather old set of problems brings the point of doing
something only on HEAD, surely.
Another thing which has crossed my mind would be get completely rid of
QualifiedNameGetCreationNamespace and replace it with a set of RangeVar
on which we could apply RangeVarGetAndCheckCreationNamespace. And we
expect callers to check for ACL_CREATE on the namespace in all cases.
That would simplify handling for all objects ... Do you think that this
would be acceptable? I am talking about objects which can be
schema-qualified.
--
Michael