Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace

From: Andres Freund <andres(at)anarazel(dot)de>
To: pgsql-hackers(at)lists(dot)postgresql(dot)org,Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>,Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Jimmy Yih <jyih(at)pivotal(dot)io>,pgsql-hackers(at)postgresql(dot)org
Subject: Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace
Date: 2018-09-05 04:29:07
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On September 4, 2018 9:11:25 PM PDT, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Michael Paquier <michael(at)paquier(dot)xyz> writes:
>> On Tue, Sep 04, 2018 at 03:09:21PM -0700, Jimmy Yih wrote:
>>> When an empty namespace is being initially populated with certain
>>> it is possible for a DROP SCHEMA operation to come in and delete the
>>> namespace without using CASCADE.
>> It seems to me that we are missing some dependency tracking in some
>> those cases.
>No, I think Jimmy is right: it's a race condition. The pg_depend entry
>would produce the right result, except that it's not committed yet so
>the DROP SCHEMA doesn't see it.
>The bigger question is whether we want to do anything about this.
>Historically we've not bothered with locking on database objects that
>don't represent storage (ie, relations and databases). If we're going
>take this seriously, then we should for example also acquire lock on
>function that's referenced in a view definition, to ensure it doesn't
>away before the view is committed and its dependencies become visible.
>Likewise for operators, opclasses, collations, text search objects, you
>name it. And worse, we'd really need this sort of locking even in
>DML queries, since objects could easily go away before the query is
>I think that line of thought leads to an enormous increase in locking
>overhead, for which we'd get little if any gain in usability. So my
>inclination is to make an engineering judgment that we won't fix this.

Haven't we already significantly started down this road, to avoid a lot of the "tuple concurrently updated" type errors? Would expanding this a git further really be that noticeable?

Sent from my Android device with K-9 Mail. Please excuse my brevity.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2018-09-05 04:41:00 Re: pg_verify_checksums failure with hash indexes
Previous Message Tom Lane 2018-09-05 04:16:00 Re: pg_verify_checksums failure with hash indexes