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
signature.asc
Description: PGP signature