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 1jqKmu-0006hR-F0 for pgsql-performance@arkaria.postgresql.org; Tue, 30 Jun 2020 18:15:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jqKmt-0005Z9-6M for pgsql-performance@arkaria.postgresql.org; Tue, 30 Jun 2020 18:15:19 +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 1jqIq5-0001Vs-27 for pgsql-performance@lists.postgresql.org; Tue, 30 Jun 2020 16:10:29 +0000 Received: from gateway31.websitewelcome.com ([192.185.143.46]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jqIq0-0007db-DX for pgsql-performance@lists.postgresql.org; Tue, 30 Jun 2020 16:10:27 +0000 Received: from cm12.websitewelcome.com (cm12.websitewelcome.com [100.42.49.8]) by gateway31.websitewelcome.com (Postfix) with ESMTP id F375216568B for ; Tue, 30 Jun 2020 11:10:22 -0500 (CDT) Received: from host2097.hostmonster.com ([67.20.114.243]) by cmsmtp with SMTP id qIpyjYfW4zOauqIpyjlv3s; Tue, 30 Jun 2020 11:10:22 -0500 X-Authority-Reason: nr=8 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=pragmaticdata.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:Date:Message-ID:Subject:From:To:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=WCG5Jo7bj9YZcus/kZvh4kVe07KpLRuIICDjGVtGbPE=; b=lYY+Elw4xlP4XBEb5YdflsVtkr QIHNH+tEB1zf1JaFLjGRwwUhxqm8YBB6cIR77QTR1gEY77vUUyD0p+6j5xeYan850kXJ3yUnxBVne LGxuYfwGh3tRss5GULo5ZXBrq; Received: from [177.143.140.96] (port=64236 helo=[10.0.0.103]) by host2097.hostmonster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1jqIpx-000NmR-Qc for pgsql-performance@lists.postgresql.org; Tue, 30 Jun 2020 10:10:22 -0600 To: pgsql-performance@lists.postgresql.org From: Gunther Schadow Subject: Is there a known bug with SKIP LOCKED and "tuple to be locked was already moved to another partition due to concurrent update"? Message-ID: <4f379a07-c49b-14dd-ddba-e0aaf37235d5@pragmaticdata.com> Date: Tue, 30 Jun 2020 12:10:17 -0400 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host2097.hostmonster.com X-AntiAbuse: Original Domain - lists.postgresql.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - pragmaticdata.com X-BWhitelist: no X-Source-IP: 177.143.140.96 X-Source-L: No X-Exim-ID: 1jqIpx-000NmR-Qc X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([10.0.0.103]) [177.143.140.96]:64236 X-Source-Auth: gunther@pragmaticdata.com X-Email-Count: 2 X-Source-Cap: cHJhZ21hdDE7cHJhZ21hdDE7aG9zdDIwOTcuaG9zdG1vbnN0ZXIuY29t X-Local-Domain: yes List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hi all, long time ago I devised with your help a task queuing system which uses SELECT ... FOR UPDATE SKIP LOCKED for many parallel workers to find tasks in the queue, and it used a partitioned table where the hot part of the queue is short and so the query for a job is quick and the skip locked locking makes sure that one job is only assigned to one worker. And this works pretty well for me, except that when we run many workers we find a lot of these failures occurring: "tuple to be locked was already moved to another partition due to concurrent update" This would not exactly look like a bug, because the message says "to be locked", so at least it's not allowing two workers to lock the same tuple. But it seems that the skip-locked mode should not make an error out of this, but treat it as the tuple was already locked. Why would it want to lock the tuple (representing the job) if another worker has already finished his UPDATE of the job to mark it as "done" (which is what makes the tuple move to the "completed" partition.) Either the SELECT for jobs to do returned a wrong tuple, which was already update, or there is some lapse in the locking. Either way it would seem to be a waste of time throwing all these errors when the tuple should not even have been selected for update and locking. I wonder if anybody knows anything about that issue? Of course you'll want to see the DDL and SQL queries, etc. but you can't really try it out unless you do some massively parallel magic. So I figured I just ask. regards, -Gunther