Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace
Date
Msg-id 7856.1536438094@sss.pgh.pa.us
Whole thread Raw
In response to Re: Prevent concurrent DROP SCHEMA when certain objects are beinginitially created in the namespace  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Prevent concurrent DROP SCHEMA when certain objects are beinginitially created in the namespace  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Michael Paquier <michael@paquier.xyz> writes:
> This way if any refactoring is done with this routine, then we don't
> break schema lock logic.  Andres, Tom and others, any objections?

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
and (b) there's been no discussion about cost-benefit tradeoffs.
What's it going to cost us in terms of additional locking --- not
only performance, but the potential for new deadlock cases ---
and does this really fix enough real-world problems to be worth it?

            regards, tom lane


pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Does logical replication slot itself would be physicallyreplicated to slaves?
Next
From: Michael Paquier
Date:
Subject: Re: Prevent concurrent DROP SCHEMA when certain objects are beinginitially created in the namespace