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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Fabrízio de Royes Mello <fabriziomello(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, jyih(at)pivotal(dot)io
Subject: Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace
Date: 2018-09-08 20:21:34
Message-ID: 7856.1536438094@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-09-08 21:09:31 Re: Prevent concurrent DROP SCHEMA when certain objects are being initially created in the namespace
Previous Message Michael Paquier 2018-09-08 20:07:21 Re: Does logical replication slot itself would be physically replicated to slaves?