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 1kUf3s-0007Qi-FA for pgsql-bugs@arkaria.postgresql.org; Mon, 19 Oct 2020 23:59:32 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kUf3q-0005x0-1Z for pgsql-bugs@arkaria.postgresql.org; Mon, 19 Oct 2020 23:59:30 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kUf3p-0005uy-H5 for pgsql-bugs@lists.postgresql.org; Mon, 19 Oct 2020 23:59:29 +0000 Received: from mail-il1-x12d.google.com ([2607:f8b0:4864:20::12d]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1kUf3m-0001HO-Cw for pgsql-bugs@lists.postgresql.org; Mon, 19 Oct 2020 23:59:28 +0000 Received: by mail-il1-x12d.google.com with SMTP id j17so63781ilr.2 for ; Mon, 19 Oct 2020 16:59:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=endpoint.com; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=pjQ4kaaWCviTYrjTizRMB8X7AZPzE8NbQbOLJTo3mcg=; b=LdN21X0H9eLlTGuUxdlKH3JxgkoYEiGsvvmoKfxODItOgb1ciL2vm9cDj3LvbvNJSz mrOhYUbYFcVVqnEj75z1KVMmgQDfaSIElm8e7RPTbS299XE4DSqLlm0U4IhN8wM/ZO41 qyIf+8xIwmlB0zaXsJiY0zqTimksqmhS5lJiUNHYR2+piN/DPAOFB2tzEomOd6SvdUlR 3nQL610NyDYm9mE98dzHAgFEhxHlBoR9D/3fWwQobNwngDpFbRdLujcJf4VvpcdSaDcm FsK3KJ34NnCvTTgFXWeoqCrDUil74Xhj75C7wJEznJMRZZO1FL2NXQV3vYD5/43iL5kz kKnw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=pjQ4kaaWCviTYrjTizRMB8X7AZPzE8NbQbOLJTo3mcg=; b=bdJzVpf48h90vyFIS5aez4X0bgASjjcd69aWxCz9d3xHzI++mS51jwbWwIdnUDmLwj Quia2mQPngjdhP3ELJLuXyZ4OROmpv9yR6uxniftXQ8bENeckKT0kkehclWKFjmFNf1X UmfI2tkzqdsZBQ46UhWTWrhjX3bYvbRClY1Nqz6J24aNQ0rioMmN4BY81wssQZylp1+q jfGzjMGo+cslSjgwV9rYFrch0meuvplgivJ8BK/IlX6Y9Oi0OEi+B4iBuBJWRQSslrBb IdHSw5xSPRRCMmkhamzM5q9D3IZfXqr/jyufAlRDOjXtFOzWY5CEwvWV3sBk5WPwz8WM oHLg== X-Gm-Message-State: AOAM531o7QHE0YMeG2LZgm2h1KsNa+fD9R4ENTy4DqG7/WqG0FeN96Vo 2rM0Sfvv9kPewloLrtJBvsUYGOgopVOFQw== X-Google-Smtp-Source: ABdhPJzLEvxSe4w6C727hbtYPd6AlnM+7nbxeFu63t9fOxkAFR1gcG1Ft+c/cgJ4MdWt4/7jeMN4xw== X-Received: by 2002:a92:5f5b:: with SMTP id t88mr2291018ilb.170.1603151964059; Mon, 19 Oct 2020 16:59:24 -0700 (PDT) Received: from ?IPv6:2600:100a:b02e:444e:cd80:2d17:9a60:8424? ([2600:100a:b02e:444e:cd80:2d17:9a60:8424]) by smtp.gmail.com with ESMTPSA id c1sm177319ile.0.2020.10.19.16.59.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Oct 2020 16:59:22 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: David Christensen Mime-Version: 1.0 (1.0) Subject: Re: BUG #16676: SELECT ... FETCH FIRST ROW WITH TIES FOR UPDATE SKIP LOCKED locks rows it doesn't return Date: Mon, 19 Oct 2020 18:59:21 -0500 Message-Id: <7B98FC76-00EE-4441-AF10-A4A805DC021E@endpoint.com> References: <565608.1603148830@sss.pgh.pa.us> Cc: pgsql-bugs@lists.postgresql.org In-Reply-To: <565608.1603148830@sss.pgh.pa.us> To: Tom Lane X-Mailer: iPhone Mail (18A393) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk > On Oct 19, 2020, at 6:07 PM, Tom Lane wrote: >=20 > =EF=BB=BFDavid Christensen writes: >> Proposed fix: >> Reorder Limit/LockRows nodes to prevent locking extra tuples in FETCH FIR= ST WITH TIES >=20 > Isn't that going to break more cases than it fixes? In the case of Limit, isn=E2=80=99t LockRows supposed to only lock the numbe= r of actual rows returned? What are the scenarios that this might break and do you have any ideas for a= lternate fixes? David=