Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vwEzX-00BmLT-0t for pgsql-hackers@arkaria.postgresql.org; Sat, 28 Feb 2026 07:44:00 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vwEzV-00AOpf-2q for pgsql-hackers@arkaria.postgresql.org; Sat, 28 Feb 2026 07:43:57 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vwEzV-00AOpW-0u for pgsql-hackers@lists.postgresql.org; Sat, 28 Feb 2026 07:43:57 +0000 Received: from mail.postgrespro.ru ([93.174.132.70]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vwEzQ-00000001e1i-3aTv for pgsql-hackers@lists.postgresql.org; Sat, 28 Feb 2026 07:43:55 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mx2023; t=1772264630; bh=RtrJhDfMPICFB/vykY4bsvmAunn8n8Pwq/AX/cCNoBE=; h=Message-ID:Date:User-Agent:Subject:To:Cc:References:From: In-Reply-To:From; b=r0ZZ/hoYDcCHLXWh5abTF/mCirQmSg5ucwIMi2fYl+1ibeEG2KO+w9+d5evlJwZul RG/h9iz77+2FicsALn3n1vVmbkm+sfup83L78RRsASC/J3Ln/uh2V4Mb/z48irsABM D5hl+H2VAEoFqlYOgMrtw2g5FdtcVFmFFTxOFr9dOxQ3hq9e2O+OLihncqxWoQ52EZ YaM17FTiOgN+PJZiYdZ/f316pK7a/ea2zGkr7SKOaadMd1aDfk8EWu5EghWwvesEzm Bpgxk0/ydx1N0aYd5wDbdJk9wzD77+uauWETnAOSpn3pMJPj3MM2n4iKsa1IQCyR+r 9tuGXJCyqnxCg== Received: from [192.168.3.107] (broadband-5-228-113-160.ip.moscow.rt.ru [5.228.113.160]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: y.sokolov@postgrespro.ru) by mail.postgrespro.ru (Postfix/465) with ESMTPSA id 7A57260BA8; Sat, 28 Feb 2026 10:43:49 +0300 (MSK) Message-ID: Date: Sat, 28 Feb 2026 10:43:49 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Fix bug in multixact Oldest*MXactId initialization and access To: Sami Imseih Cc: "pgsql-hackers@lists.postgresql.org" , Heikki Linnakangas , Andres Freund , Chao Li References: <7acc94b0-ea82-4657-b1b0-77842cb7a60c@postgrespro.ru> <93F0BD0A-0B8B-4592-9D4B-53F405A86F6A@gmail.com> <3d7a2207-0e61-4d95-bc00-e5248956a32b@postgrespro.ru> <366b6f95-613d-4ef8-82e4-bb2fd06d9c4d@iki.fi> Content-Language: en-US From: Yura Sokolov In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-KSMG-AntiPhishing: NotDetected X-KSMG-AntiSpam-Interceptor-Info: not scanned X-KSMG-AntiSpam-Status: not scanned, disabled by settings X-KSMG-AntiVirus: Kaspersky Secure Mail Gateway, version 2.1.0.7854, bases: 2026/02/28 05:48:00 #28233146 X-KSMG-AntiVirus-Status: NotDetected, skipped X-KSMG-LinksScanning: not scanned, disabled by settings X-KSMG-Message-Action: skipped X-KSMG-Rule-ID: 1 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 27.02.2026 21:51, Sami Imseih пишет: > It's unfortunately a bit worse. Here is a repro that shows 2 prepared > transactions > being created after a shared lock is taken on a table with 1 row. A subsequent > delete is able to complete, where we would expect it to be blocked until the > prepared transactions COMMIT or ROLLBACK. OH MY GOD!!!! I saw very similar behavior in dump of production WAL logs from our client. Main issue were in other subsystem in that case, that is why we didn't dig deeper. But I clearly remembered: "Ouch, it is strange, why this row were deleted being locked for foreign key?". Great catch!!!! My deep respect to you, Sami Imseih!!!! > With simply adding NUM_AUXILIARY_PROCS to MaxOldestSlot, it works as expected, > and the delete is blocked. -- regards Yura Sokolov aka funny-falcon