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