On 2021-Feb-02, Drouvot, Bertrand wrote: > On 12/18/20 12:26 AM, Tom Lane wrote:
> > But any of these options lead to the same question: why stop there? > > An approach that would actually be defensible, perhaps, is to incorporate > > this functionality into the dependency mechanism: any time we're about to > > create a pg_depend or pg_shdepend entry, take out an AccessShareLock on > > the referenced object, and then check to make sure it still exists. > > This would improve the dependency mechanism so it prevents creation-time > > race conditions, not just attempts to drop dependencies of > > already-committed objects. > > Agree that working with pg_depend and pg_shdepend is the way to go. > > Instead of using the locking machinery (and then make the one that > would currently produce the orphaned object waiting), Jim proposed > another approach: make use of special snapshot (like a dirty one > depending of the case). > > That way instead of locking we could instead report an error, > something like this: > > postgres=# drop schema tobeorph; > ERROR: cannot drop schema tobeorph because other objects that are currently > under creation depend on it > DETAIL: function under creation tobeorph.bdttime() depends on schema tobeorph Sounds like an idea worth trying. What are the semantics of that special snapshot? Why do we need a special snapshot at all -- doesn't CatalogSnapshot serve? This item is classified as a bug-fix in the commitfest, but it doesn't sound like something we can actually back-patch. In that light, maybe it's not an actual bugfix, but a new safety feature. -- Álvaro Herrera Valdivia, Chile
