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 1jJti9-0002fj-6g for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2020 06:52:21 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jJti8-0006Md-34 for pgsql-hackers@arkaria.postgresql.org; Thu, 02 Apr 2020 06:52:20 +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 1jJti7-0006MW-OV for pgsql-hackers@lists.postgresql.org; Thu, 02 Apr 2020 06:52:19 +0000 Received: from mail-qt1-x82c.google.com ([2607:f8b0:4864:20::82c]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1jJti1-0004sp-9P for pgsql-hackers@postgresql.org; Thu, 02 Apr 2020 06:52:18 +0000 Received: by mail-qt1-x82c.google.com with SMTP id m33so2440246qtb.3 for ; Wed, 01 Apr 2020 23:52:13 -0700 (PDT) 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=Fp3CiYkyxG4EdP1PEeDfv+lyIFRyTciQ+74kui+OXkY=; b=pjCkInJRXEsMq2Oo753V49pC//0Ec+uAzI9/nluyVemLRjX7ivtXbVeCbHx0e91zqE kJzQ8wq8c01ARKbjarug2N6OCRAy5Dmjp97z+UD/onYNwnerVjiOvsKMsqo1OrhxXD9P cPkQ3fKOKVlze8bzyerzH2BZ1mUW089Ssni0j+c+nAA6n8FvB9EPozDF//v7MbR2jJVp Q1AINM2cpXy6Z/32EWaYRRBDboj5McIdtex3QjLPcUCIWLU8FzvY1Wx27nDc5RWUdL2m HRC2M6KdOSwI12RnHa6GkSoTiSX3k87KhX9Jwp0Vg4QK6n6eJv6STcQ3/unWp2EXT5pV QxAA== 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=Fp3CiYkyxG4EdP1PEeDfv+lyIFRyTciQ+74kui+OXkY=; b=kTrLtk42bE5OII+wfEPqxPd38GxvVIsArk08HwihFfDiyA1ZTJpTZdq5/0qQ/0ytxD W9zDa671A6g3/9nXR5dJWurYznKOhkSsMCziquKAFi/xtdilaQs4WdI5wCRqWj8ciBvb CDFvL6qk+k5zCU0tqfU+ahKirLg/vNAk87vsplh1oSl+zc9UZ8o6NEwyeLqdK2gBhpPP 4AtsVDteHtCb84qnulwaZy5aIomO3MwiN6hvCNdE3XzQMquD0oNxm+NbzAPUGuIkh5TE KHouz1UZdBEgUILzGZlU3MT/Va0PIs3FWAst6zOB4oOJCFYJ2BQ1y57VO2LGFUO4Ky/z tcIA== X-Gm-Message-State: AGi0Pual3CVnhb8j+osnZla/lgkh5I4zNj4PevWRAuJNQNs8Es6nJ7me lHar0Ovxp6qrNYZl96AcCnjB/g== X-Google-Smtp-Source: APiQypJamoZvZN3c1svzeqA0B3n5O6vl1eu9+suhMadLmZCER543fKfBj9P/9YoFp2FaD/b750ciiw== X-Received: by 2002:ac8:6c8:: with SMTP id j8mr1491869qth.392.1585810332380; Wed, 01 Apr 2020 23:52:12 -0700 (PDT) Received: from pryzbyj (charmander.telsasoft.com. [50.244.222.1]) by smtp.gmail.com with ESMTPSA id m5sm1359271qtk.85.2020.04.01.23.52.10 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Apr 2020 23:52:11 -0700 (PDT) Received: by pryzbyj (Postfix, from userid 1000) id BC3B5800755; Thu, 2 Apr 2020 01:52:09 -0500 (CDT) Date: Thu, 2 Apr 2020 01:52:09 -0500 From: Justin Pryzby To: Michael Paquier Cc: Alvaro Herrera , Amit Langote , Tom Lane , pgsql-hackers@postgresql.org Subject: Re: ALTER tbl rewrite loses CLUSTER ON index Message-ID: <20200402065209.GF14618@telsasoft.com> References: <20200316132731.GJ26184@telsasoft.com> <20200316142523.GA14606@alvherre.pgsql> <20200317053332.GE2206@paquier.xyz> <20200317162044.GX26184@telsasoft.com> <20200318024837.GG214947@paquier.xyz> <20200402061421.GA112468@paquier.xyz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200402061421.GA112468@paquier.xyz> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Thu, Apr 02, 2020 at 03:14:21PM +0900, Michael Paquier wrote: > Now, regarding patch 0002, note that you have a problem for this part: > - tuple = SearchSysCache1(INDEXRELID, ObjectIdGetDatum(indexOid)); > - if (!HeapTupleIsValid(tuple)) /* probably can't happen */ > - { > - relation_close(OldHeap, AccessExclusiveLock); > - pgstat_progress_end_command(); > - return; > - } > - indexForm = (Form_pg_index) GETSTRUCT(tuple); > - if (!indexForm->indisclustered) > + if (!get_index_isclustered(indexOid)) > { > - ReleaseSysCache(tuple); > relation_close(OldHeap, AccessExclusiveLock); > pgstat_progress_end_command(); > return; > } > - ReleaseSysCache(tuple); > > On an invalid tuple for pg_index, the new code would issue an error, > while the old code would just return. And it seems to me that this > can lead to problems because the parent relation is processed and > locked at the beginning of cluster_rel(), *after* we know the index > OID to work on. > The refactoring is fine for the other two areas > though, so I think that there is still value to apply > get_index_isclustered() within mark_index_clustered() and cluster(), > and I would suggest to keep 0002 to that. > > Justin, what do you think? Sounds right. Or else get_index_isclustered() could be redefined to take a boolean "do_elog" flag, and if syscache fails and that's false, then return false instead of ERROR. -- Justin