Date: Thu, 25 Mar 2021 18:08:27 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Amit Langote <amitlangote09@gmail.com>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: ALTER TABLE .. DETACH PARTITION CONCURRENTLY
Message-ID: <20210325210827.GA32484@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20201201013051.GA24052@telsasoft.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: 
 <https://www.postgresql.org/message-id/20210325210827.GA32484%40alvherre.pgsql>
Precedence: bulk

On 2020-Nov-30, Justin Pryzby wrote:

> On Tue, Nov 03, 2020 at 08:56:06PM -0300, Alvaro Herrera wrote:

> > * On the first transaction (the one that marks the partition as
> > detached), the partition is locked with ShareLock rather than
> > ShareUpdateExclusiveLock.  This means that DML is not allowed anymore.
> > This seems a reasonable restriction to me; surely by the time you're
> > detaching the partition you're not inserting data into it anymore.
> 
> I don't think it's an issue with your patch, but FYI that sounds like something
> I had to do recently: detach *all* partitions of various tabls to promote their
> partition key column from timestamp to timestamptz.  And we insert directly
> into child tables, not routed via parent.
> 
> I don't your patch is still useful, but not to us.  So the documentation should
> be clear about that.

FWIW since you mentioned this detail specifically: I backed away from
doing this (and use ShareUpdateExclusive), because it wasn't buying us
anything anyway.  The reason for it is that I wanted to close the hole
for RI queries, and this seemed the simplest fix; but it really *wasn't*
a fix anyway.  My later games with the active snapshot (which are
present in the version I pushed) better close this problem.  So I don't
think this would be a problem.

-- 
Álvaro Herrera       Valdivia, Chile