Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jdv1E-0003wI-FI for pgsql-bugs@arkaria.postgresql.org; Wed, 27 May 2020 12:18:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jdv1D-0007bj-9L for pgsql-bugs@arkaria.postgresql.org; Wed, 27 May 2020 12:18:47 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jdv1D-0007bc-3U for pgsql-bugs@lists.postgresql.org; Wed, 27 May 2020 12:18:47 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jdv1B-0007XM-0X for pgsql-bugs@lists.postgresql.org; Wed, 27 May 2020 12:18:46 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id 04RCIhQC005817; Wed, 27 May 2020 08:18:43 -0400 From: Tom Lane To: Michael Paquier cc: Andrey Klychkov , Peter Eisentraut , pgsql-bugs@lists.postgresql.org Subject: Re: Re[2]: In-reply-to: <20200527074736.GG103662@paquier.xyz> References: <1590486572.205117372@f500.i.mail.ru> <1590501239.839686286@f437.i.mail.ru> <17907.1590504619@sss.pgh.pa.us> <20200527074736.GG103662@paquier.xyz> Comments: In-reply-to Michael Paquier message dated "Wed, 27 May 2020 16:48:53 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <5815.1590581923.1@sss.pgh.pa.us> Date: Wed, 27 May 2020 08:18:43 -0400 Message-ID: <5816.1590581923@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Michael Paquier writes: > On Tue, May 26, 2020 at 10:50:19AM -0400, Tom Lane wrote: >> ... Perhaps the >> documentation isn't clear enough about that, but I don't see a >> bug there. > There is a paragraph about the handling of invalid indexes on the > reindex page: Yeah, but the OP is invoking this via reindexdb. Do we need to have anything about it on the reindexdb page? regards, tom lane