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 1i8Oys-0001RL-7z for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Sep 2019 13:17:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1i8Oyr-0005k7-1N for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Sep 2019 13:17:49 +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 1i8OxQ-0006Ja-7D for pgsql-hackers@lists.postgresql.org; Thu, 12 Sep 2019 13:16:20 +0000 Received: from mail-qk1-x742.google.com ([2607:f8b0:4864:20::742]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1i8OxM-00057j-RL for pgsql-hackers@postgresql.org; Thu, 12 Sep 2019 13:16:19 +0000 Received: by mail-qk1-x742.google.com with SMTP id u186so649266qkc.5 for ; Thu, 12 Sep 2019 06:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=0EG6vqNDcXyz5OJaaBJJEsvyQlfEXPCmkTxTF8svvLo=; b=oBNOJcCsRuwvaXFSBJ9jUoy7nDLlqumQ/DMyYFJjV2Nfeiwn1xfL0dfX9SidSX8skT Zgt0/D+jebyLzeQB4D4+gZg0AIiDo98rOeal5usoPGANzYOUNwPA7uE2fOG2TwmUUKPD ctd80XkbjmVXoggf2Xe1EZDXR+8QHmf9bcl2I5ie9Bapx3Nl56OYqExdqu71LKhweEBN WlHJUEsFKmvg7+EiCHOUpQb6GKCDl+FGXQ+QeLCL6rsYLY6Mzg6TpKc4+PbtanZLeU9G jZ7LxA4QVdiGBNm+28ZbPjgOYwT9MulUUjeT+kEH3o7R/s86Pv+a6e0Atdt/tubbAoKG rANA== 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:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=0EG6vqNDcXyz5OJaaBJJEsvyQlfEXPCmkTxTF8svvLo=; b=gF+bd0f9aFRuSO0pxGmS6lnQ13ZvOuWcumubOLQzbO3fpJO2Gf5Bb+byO8xZxGr3CE yQgGI7ySEo+K/+nXZjQACbj5Z+6p5Q8q30pj7YjZ5WSHE5B268QmoqRFGJRyUg6Mz7Iz arf8HfZXtAcDwcwQH1mqX4wRCCIR0ZhqtdqAAoOoyovIk8zFpOWkcTRFLdieUXs3vTgp Jgb8GRNAD2JKzvcI/dqg/wZNfJK3BZX8ROx/pKfAMeZTe9+5H0KyQpMSLXSRp8q7tjVx ugxI4eyJp5PqtW0XFbx/y6jfMVdn5M024Z6mBnWQxmQTqYJihCbRR1lHdt0cQaEEI3yZ OC+g== X-Gm-Message-State: APjAAAV4CyFkCwrGGZsgvg8EvZ+HVH8h9efpBCSyLyC3rtXPN8F77vaM WtTwaBMDTFBhI6iusR/7S7LdLuaDxc29VlMAoDczRdrTt0PHIjKHes+Hu2sRPpv7V2LHjX5iAYS Kw0ZLpAPLv1khiDFhRPdXI/KHr7pWjdMzwnK1UjdixCLoVtC/QKK0Zb6Zvj0mLQoc1HtrXlqDoL C8z21e7w== X-Google-Smtp-Source: APXvYqx/zouuY0XEz4Yjdfjr78sYvTMQB82vrXfV3rYmrnUIwoEAwTXCk4NVV5eWyxv+FEWv2u1MRw== X-Received: by 2002:a37:a845:: with SMTP id r66mr40423498qke.289.1568294175068; Thu, 12 Sep 2019 06:16:15 -0700 (PDT) Received: from nimloth.alvh.no-ip.org ([179.56.30.174]) by smtp.gmail.com with ESMTPSA id c29sm15552177qtc.89.2019.09.12.06.16.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 12 Sep 2019 06:16:14 -0700 (PDT) Received: by nimloth.alvh.no-ip.org (Postfix, from userid 1000) id EC90B12090A; Thu, 12 Sep 2019 10:16:12 -0300 (-03) Date: Thu, 12 Sep 2019 10:16:12 -0300 From: Alvaro Herrera To: Andrey Borodin Cc: PostgreSQL Hackers Subject: Re: Amcheck: do rightlink verification with lock coupling Message-ID: <20190912131612.GA24926@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0EB0CFA8-CBD8-4296-8049-A2C0F28FAE8C@yandex-team.ru> User-Agent: Mutt/1.9.4 (2018-02-28) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2019-Sep-12, Andrey Borodin wrote: > This patch violates one of amcheck design principles: current code > does not ever take more than one page lock. I do not know: should we > hold this rule or should we use more deep check? The check does seem worthwhile to me. As far as I know, in btree you can lock the right sibling of a page while keeping lock on the page itself, without risk of deadlock. So I'm not sure what's the issue with that. This is in the README: In most cases we release our lock and pin on a page before attempting to acquire pin and lock on the page we are moving to. In a few places it is necessary to lock the next page before releasing the current one. This is safe when moving right or up, but not when moving left or down (else we'd create the possibility of deadlocks). I suppose Peter was concerned about being able to run amcheck without causing any trouble at all for concurrent operation; maybe we can retain that property by making this check optional. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services