Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j5Sj4-00026Y-CL for pgsql-hackers@arkaria.postgresql.org; Sat, 22 Feb 2020 11:13:38 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1j5Sj1-0005bj-O7 for pgsql-hackers@arkaria.postgresql.org; Sat, 22 Feb 2020 11:13:35 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1j5Sj1-0005Zf-7W for pgsql-hackers@lists.postgresql.org; Sat, 22 Feb 2020 11:13:35 +0000 Received: from mail-yb1-xb44.google.com ([2607:f8b0:4864:20::b44]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1j5Siu-00026O-SC for pgsql-hackers@postgresql.org; Sat, 22 Feb 2020 11:13:32 +0000 Received: by mail-yb1-xb44.google.com with SMTP id u26so2151777ybd.3 for ; Sat, 22 Feb 2020 03:13:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telsasoft-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=DtCYX83LhovS5M8ika0trXytBrp2qirmduElH0c2AP4=; b=fCXLyaJHxIdGqZ3sFAU90+Mu3Io0CndZGQCcECM7OgG0JI2DMvhScegsnp7+Aze9pe JPQMZDApicV95TooBU7wNjrQRzyLquqF2TPMg3KFmuQotexPgnT79Webtm0kuDLkwFVx Tu3Rt7oZ9VsKkjK9GoKS9B/m3+nhab4ZJ5VJTLyAdBwQExQhDVWWCsKl1tbNQbrY5a24 0CjR+t3IDf0HtQqszxaP+T34rvrbB/npWPx2046yj0zu3Sb4JuHNd9/GLXAqOQ4dUlEE xO2m+gs1T51ANnItGnDSndZcSgpOfSHFGOLiLWiCkDEtMylmX19SL69IZCL9ggacOdy3 TsHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=DtCYX83LhovS5M8ika0trXytBrp2qirmduElH0c2AP4=; b=HAX+eDL4E9Hg1XU/d8it17FdHQmsM3rXTHsMjhh7FlaFjwCPkVnoc9MYzoadGbRNB9 dJYHscJkHg8ELHroeM9CN7kfCw2Qo25OcZaS9vjPMnBXfJ8Rimn/XeJW3DbxTGxI4L2M VO6qDBlKBMDXxSNr8XzFwz5BciMgWpc+lZxWaZfPAIwGVZM5+QBGzkMypz3ilFMBLS5n RMERGkU9PXWNdcpYJuo3m38+skle/1p9Tb/LwXcaJw1XAIm3mU7oQV50OQpi+xszRr4I UTzJcyw8JGwPSg8viibOE654Ikt7gJA452+S01dEHWo4C8sLJSvsKguzzzgTp93Y2B1L znCA== X-Gm-Message-State: APjAAAVRV7F8MV+11RrUkiLmHFL7h5wTE12B16JEFgYIZJ6VpfJki3Ml rVtDDRTpY3zQbrKc41Uqujy/ok6L1kI= X-Google-Smtp-Source: APXvYqwXikfXffZC64kP0bHfSwgKQPNTw7WZiMHxccT8BlBkz6vGjQc7LGlN5k1qvdu4DXDBXgxz1g== X-Received: by 2002:a25:5cc4:: with SMTP id q187mr37239752ybb.122.1582370004321; Sat, 22 Feb 2020 03:13:24 -0800 (PST) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id d199sm2509534ywh.83.2020.02.22.03.13.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 22 Feb 2020 03:13:23 -0800 (PST) Received: by pryzbyj (Postfix, from userid 1000) id F36B6800925; Sat, 22 Feb 2020 05:13:19 -0600 (CST) Date: Sat, 22 Feb 2020 05:13:19 -0600 From: Justin Pryzby To: Michael Paquier Cc: Sergei Kornilov , Peter Eisentraut , Michael Paquier , Andreas Karlsson , pgsql-hackers@postgresql.org Subject: Re: reindex concurrently and two toast indexes Message-ID: <20200222111319.GS31889@telsasoft.com> References: <20200216190835.GA21832@telsasoft.com> <20200218052933.GH4176@paquier.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200218052933.GH4176@paquier.xyz> User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Tue, Feb 18, 2020 at 02:29:33PM +0900, Michael Paquier wrote: > On Sun, Feb 16, 2020 at 01:08:35PM -0600, Justin Pryzby wrote: > > Forking old, long thread: > > https://www.postgresql.org/message-id/36712441546604286%40sas1-890ba5c2334a.qloud-c.yandex.net > > On Fri, Jan 04, 2019 at 03:18:06PM +0300, Sergei Kornilov wrote: > >> About reindex invalid indexes - i found one good question in archives [1]: how about toast indexes? > >> I check it now, i am able drop invalid toast index, but i can not drop reduntant valid index. > >> Reproduce: > >> session 1: begin; select from test_toast ... for update; > >> session 2: reindex table CONCURRENTLY test_toast ; > >> session 2: interrupt by ctrl+C > >> session 1: commit > >> session 2: reindex table test_toast ; > >> and now we have two toast indexes. DROP INDEX is able to remove > >> only invalid ones. Valid index gives "ERROR: permission denied: > >> "pg_toast_16426_index_ccnew" is a system catalog" > >> [1]: https://www.postgresql.org/message-id/CAB7nPqT%2B6igqbUb59y04NEgHoBeUGYteuUr89AKnLTFNdB8Hyw%40mail.gmail.com > > > > It looks like this was never addressed. > > On HEAD, this exact scenario leads to the presence of an old toast > index pg_toast.pg_toast_*_index_ccold, causing the index to be skipped > on a follow-up concurrent reindex: > =# reindex table CONCURRENTLY test_toast ; > WARNING: XX002: cannot reindex invalid index > "pg_toast.pg_toast_16385_index_ccold" concurrently, skipping > LOCATION: ReindexRelationConcurrently, indexcmds.c:2863 > REINDEX > > And this toast index can be dropped while it remains invalid: > =# drop index pg_toast.pg_toast_16385_index_ccold; > DROP INDEX > > I recall testing that stuff for all the interrupts which could be > triggered and in this case, this waits at step 5 within > WaitForLockersMultiple(). Now, in your case you take an extra step > with a plain REINDEX, which forces a rebuild of the invalid toast > index, making it per se valid, and not droppable. > > Hmm. There could be an argument here for skipping invalid toast > indexes within reindex_index(), because we are sure about having at > least one valid toast index at anytime, and these are not concerned > with CIC. Julien sent a patch for that, but here are my ideas (which you are free to reject): Could you require an AEL for that case, or something which will preclude reindex table test_toast from working ? Could you use atomic updates to ensure that exactly one index in an {old,new} pair is invalid at any given time ? Could you make the new (invalid) toast index not visible to other transactions? -- Justin Pryzby