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 1kdEdV-0006Z7-PN for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Nov 2020 15:35:45 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kdEdU-0001i1-6L for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Nov 2020 15:35:44 +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 1kdEdT-0001ht-Te for pgsql-hackers@lists.postgresql.org; Thu, 12 Nov 2020 15:35:43 +0000 Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from <9erthalion6@gmail.com>) id 1kdEdR-0007aR-51 for pgsql-hackers@lists.postgresql.org; Thu, 12 Nov 2020 15:35:42 +0000 Received: by mail-ed1-x529.google.com with SMTP id t9so6744678edq.8 for ; Thu, 12 Nov 2020 07:35:40 -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=y7aWIfEz61M5rcxmyqlv3Y3zDbZJnRwcX5aazqoVWZY=; b=q5aQi9YfYIx7ikA/TQoJmXHaMBLh9bgJ7Iw5KFSr+YOM+k7qsgGuUHRpZt7e8NrX9H 777g36vhPl8zrAc4Hl/On+A8VBLEXJdNmTERbLUP3xdbXxPKlr9QPhk8PHPi5reRD1em dg81iCKnaEIihcxQ4Gz9Sx5xXWD3d5oa/tlTRPaBklkWFc4WzzdONxg4IGKpHtNfQiu1 HhRNtZQYxkHnX4uskx3ajoG0UlqK+mJb8DDqj5RHpbU7Z5ixo8wEnVaSexz2Yrk3J82B kCTw6E6efz1OU6r9VSJtIZgxKT4M9jn7blKQ+Blj/YUtPBslte7Zh70bxEGR9qSU+EKP Yr9g== 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=y7aWIfEz61M5rcxmyqlv3Y3zDbZJnRwcX5aazqoVWZY=; b=L4iOCiv82CQ3b7CTByAIDb5TFPycTq7f2TyBnUflio3TiEh+57uDiZsZXgyrctZpUM mB+qIyEdY0JV5Y5AoUQEPCepH7lkFBwdRWNC6b1VsegYoJcFfSjh/ENu26uvV/qFKF4n 8jIwvGMcSyaxoxB83ZKCgMo8YKHEZIss2d/JieyKNhEywuLqsC9M7HkhXOSR9eGqqGnd P7F3Byegr7BPqUKUZgtn9gmAQ89+HBjLwuP9RbVNHZbb9NO5byQZoKQhgxBOI+IBA36V VJemggoBkjV/AVvrcv5qynn9meOOj4i1tAmnzzIA+QZDxlxTskXP3Mz+PZd79mugMxI2 YCzA== X-Gm-Message-State: AOAM531qBLprWFGC75C57/+wwpjzXudWlMREHs+TnepSasm1xOPZ9VHX cscZf00cyaJPHsdyGbL/T0g= X-Google-Smtp-Source: ABdhPJzs4FmELbKZkhMduKgcNahq/Qa6bIA8sH4JapQ4eB9MTmF8zYaix1s71JDoF0K1dE53X+S0ZA== X-Received: by 2002:a05:6402:43:: with SMTP id f3mr262355edu.373.1605195339670; Thu, 12 Nov 2020 07:35:39 -0800 (PST) Received: from localhost (dslb-188-102-101-219.188.102.pools.vodafone-ip.de. [188.102.101.219]) by smtp.gmail.com with ESMTPSA id m2sm2513242eds.35.2020.11.12.07.35.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Nov 2020 07:35:38 -0800 (PST) Date: Thu, 12 Nov 2020 16:36:32 +0100 From: Dmitry Dolgov <9erthalion6@gmail.com> To: Tom Lane Cc: Alvaro Herrera , Michael Paquier , James Coleman , Pg Hackers Subject: Re: remove spurious CREATE INDEX CONCURRENTLY wait Message-ID: <20201112153632.whecjbyvrxzdcjfv@localhost> References: <20201110023115.GA18579@alvherre.pgsql> <2091476.1604977347@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2091476.1604977347@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On Mon, Nov 09, 2020 at 10:02:27PM -0500, Tom Lane wrote: > > Alvaro Herrera writes: > > Yeah ... it would be much better if we can make it use atomics instead. > > I was thinking more like "do we need any locking at all". > > Assuming that a proc's vacuumFlags can be set by only the process itself, > there's no write conflicts to worry about. On the read side, there's a > hazard that onlookers will not see the PROC_IN_SAFE_IC flag set; but > that's not any different from what the outcome would be if they looked > just before this stanza executes. And even if they don't see it, at worst > we lose the optimization being proposed. > > There is a question of whether it's important that both copies of the flag > appear to update atomically ... but that just begs the question "why in > heaven's name are there two copies?" Sounds right, but after reading the thread about GetSnapshotData scalability more thoroughly there seem to be an assumption that those copies have to be updated at the same time under the same lock, and claims that in some cases justification for correctness around not taking ProcArrayLock is too complicated, at least for now. Interesting enough, similar discussion happened about vaccumFlags before with the same conclusion that theoretically it's fine to update without holding the lock, but this assumption could change one day and it's better to avoid such risks. Having said that I believe it makes sense to continue with locking. Are there any other opinions? I'll try to benchmark it in the meantime.