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 1kl9Ox-0001Bn-Dk for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Dec 2020 11:37:27 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kl9Ov-00042M-Nr for pgsql-hackers@arkaria.postgresql.org; Fri, 04 Dec 2020 11:37:25 +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 <9erthalion6@gmail.com>) id 1kl9Ov-00042F-Eo for pgsql-hackers@lists.postgresql.org; Fri, 04 Dec 2020 11:37:25 +0000 Received: from mail-ej1-x635.google.com ([2a00:1450:4864:20::635]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <9erthalion6@gmail.com>) id 1kl9Ot-0006je-GG for pgsql-hackers@lists.postgresql.org; Fri, 04 Dec 2020 11:37:24 +0000 Received: by mail-ej1-x635.google.com with SMTP id x16so8202392ejj.7 for ; Fri, 04 Dec 2020 03:37:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=ljdvkpRf2qnQtSffVClMwPAXiyovHOOnZyvZLkc8evw=; b=Qx8ygvXVvC1XvzXDSjRbqPBhEBfj8dqnQZMhh9akDkWMabHA94JbV3TGgFcBXg9DMo OOICxcnybuN3lx+672/a2IzGClflG7osYhDeL2DVIhZnjPh5mKztMQHviwJC0x5yuAlQ 9BPe1VKh0kC43ar8zBu3+858qimW238Xn1QlrKd+drYZAnDaaUh/DYILh6yBeX6XvR+1 smd5w+WHa4A+8o7VGTPcpyAUoUiSX4ad8Qf5gViSv3NeXRpiIxJDjEhBe1huHGdlAwUF 5JRVulCtYsE0SLSR+wvX3vD8Gj9VE8XGshtq/4BIO/+/2w+XwOYBCVkzwnvZ8yhJNLpw JCoQ== 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; bh=ljdvkpRf2qnQtSffVClMwPAXiyovHOOnZyvZLkc8evw=; b=gc1gKfIrmqxi2x6BLaRIhl+LAaPVMgFItYyiQwoET7Dg1wO5haddyG4QnFepvx3dr1 EguB/9lJKnXqZ1EsED0SOSE7WKTum97rfiuUFvw6RP4F9b8oOeryzkRg6FhElwtio7Z6 HCKAB885YzcCYEgBrxxSWHQcAAJsTAnasAiVCFZAOz72DNh7uyWWV3IjFaqtwwk3Rh7I kvCcLe18HceHzfaiifwhhbEGx3U0kCXAV1SNpkVWue9a2eiWGthdDKS29fgg9qPt4HOS NgAKHnGXoumDSGkhr9r8aUxitCc1yjQ/+jGnsGejJnkgqXOtrI7iGt2GP30LylEh6YMc i+kw== X-Gm-Message-State: AOAM53206w1BmobTYn2/OSZWnp/A31wzswSNZfnXjx1q/pLe0j8AQ1Sc blhP30U2+cCyIQaHnp498c4= X-Google-Smtp-Source: ABdhPJxM+PyYYNN+VcQSmagyBXjbpZxaNJG29Ytdd5ya56/KcWNq/ZPtKFJCP5hUKILeNAMHsIu0nA== X-Received: by 2002:a17:906:614:: with SMTP id s20mr6494799ejb.202.1607081842172; Fri, 04 Dec 2020 03:37:22 -0800 (PST) Received: from localhost (dslb-094-222-016-204.094.222.pools.vodafone-ip.de. [94.222.16.204]) by smtp.gmail.com with ESMTPSA id n14sm3241073edw.38.2020.12.04.03.37.20 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 04 Dec 2020 03:37:21 -0800 (PST) Date: Fri, 4 Dec 2020 12:38:32 +0100 From: Dmitry Dolgov <9erthalion6@gmail.com> To: Alvaro Herrera Cc: Pg Hackers , Michael Paquier , James Coleman Subject: Re: {CREATE INDEX, REINDEX} CONCURRENTLY improvements Message-ID: <20201204113832.yuneqs6t4fhjo6k3@localhost> References: <20201130195439.GA24598@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20201130195439.GA24598@alvherre.pgsql> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On Mon, Nov 30, 2020 at 04:54:39PM -0300, Alvaro Herrera wrote: > > In a previous thread [1], we added smarts so that processes running > CREATE INDEX CONCURRENTLY would not wait for each other. > > One is adding the same to REINDEX CONCURRENTLY. I've attached patch > 0002 here which does that. > > Why 0002, you ask? That's because preparatory patch 0001 simplifies the > ReindexRelationConcurrently somewhat by adding a struct to be used of > indexes that are going to be processed, instead of just a list of Oids. > This is a good change in itself because it let us get rid of duplicative > open/close of the index rels in order to obtain some info that's already > known at the start. Thanks! The patch looks pretty good to me, after reading it I only have a few minor comments/questions: * ReindexIndexInfo sounds a bit weird for me because of the repeating part, although I see there is already a similar ReindexIndexCallbackState so probably it's fine. * This one is mostly for me to understand. There are couple of places with a commentary that 'PROC_IN_SAFE_IC is not necessary, because the transaction only takes a snapshot to do some catalog manipulation'. But for some of them I don't immediately see in the relevant code anything related to snapshots. E.g. one in DefineIndex is followed by WaitForOlderSnapshots (which seems to only do waiting, not taking a snapshot), index_set_state_flags and CacheInvalidateRelcacheByRelid. Is taking a snapshot hidden somewhere there inside?