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 1mk2mo-0007Oe-SF for pgsql-bugs@arkaria.postgresql.org; Mon, 08 Nov 2021 11:26:02 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mk2mn-0006dz-Po for pgsql-bugs@arkaria.postgresql.org; Mon, 08 Nov 2021 11:26:01 +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 1mk2SG-00080a-DN for pgsql-bugs@lists.postgresql.org; Mon, 08 Nov 2021 11:04:48 +0000 Received: from mail-lj1-x230.google.com ([2a00:1450:4864:20::230]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mk2SD-0000Bl-1d for pgsql-bugs@lists.postgresql.org; Mon, 08 Nov 2021 11:04:47 +0000 Received: by mail-lj1-x230.google.com with SMTP id e11so9475883ljo.13 for ; Mon, 08 Nov 2021 03:04:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dataegret-com.20210112.gappssmtp.com; s=20210112; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding:content-language; bh=7d9RFs7jE+sRbbfCKk1UTmHJaooHkymzeR6OFhh/NXA=; b=wiWjRYbi64o/N8FniTM6cVrnmXMnwKDsXnkU2k6M+zYqjNupIHzVf8a/6+DPhqLQ/b 3NA6TRRmVAWFvYl3+EzWBPFELc2bR9nwJq4B9zIDyg+STAZtBfvMU75be1QhUUhAUMrh 2Agy0CWU9BLNMDzYIqdOsyvW9a+QG2OXHuxLpHoPM+SSJDXXk7WWOe4EdXNgA0WK4WPj YPiPhyAtZ9WaWKQULX6+zFyLbIB+YsnKys273RuvERzQnbwJUFfuKMI/xlL9Dp9iutX2 diYQC+0m5f/78N1ARS4doxEcnJeYf8e2T0mhzwl2BskVHIbC3Linkr7TBf/UQqo2nixC TyFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=7d9RFs7jE+sRbbfCKk1UTmHJaooHkymzeR6OFhh/NXA=; b=zMU1MQ7uN2NvIsZXdfoN7GaYqHza6+2EhP6fCu4q63PHx3H6oRM1eGKj0dcSUK7qGQ uCpYuQBzBaRv8lMOuHwodFz9IQKLimWxV3HSdXaE4ymiynpR9r5ZZGLMQxyQIGIywgir fFFTygECMG2f/XwBJ24Z2kEneXn14CbemoYhVj6qHSKZBM/8YDT/fdXRJOLVP609f+qC oxpdmdQPhaMnNQwbHSdvCIect8K3nc9rYQMmUTcrpk2vqHXrR7K7fNcqqYvFv9iL5nHL IaoRvMZ50QwHGSgk6d2dgvl/cwNaS2Ip5hoT5O81vkdsI3xihrJlw8UD4VCLQkuAz/st glGw== X-Gm-Message-State: AOAM533Bdz7l1qYakHOa1PJ+EuzNnZ/tlpL248bvnWwfhqo8shdk8SqI Dqa0y4nqRAJVTmNhm+bM7L/5lg== X-Google-Smtp-Source: ABdhPJx395wt2dyo7aQIfOQ/beNU27SFOVAJyaWuzEaaQuIPVz7+E9UUy8BN5tzVpCiyqGKl56ZA2Q== X-Received: by 2002:a2e:b004:: with SMTP id y4mr32908189ljk.412.1636369483213; Mon, 08 Nov 2021 03:04:43 -0800 (PST) Received: from [192.168.8.116] ([213.87.121.95]) by smtp.googlemail.com with ESMTPSA id j15sm1776379lfg.1.2021.11.08.03.04.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 08 Nov 2021 03:04:42 -0800 (PST) Subject: Re: BUG #17268: Possible corruption in toast index after reindex index concurrently To: Maxim Boguk , Andres Freund Cc: PostgreSQL mailing lists , Peter Geoghegan , Michael Paquier References: <17268-d2fb426e0895abd4@postgresql.org> From: Alexey Ermakov Message-ID: <366f7247-709e-c07c-4875-068be1121c3a@dataegret.com> Date: Mon, 8 Nov 2021 17:04:40 +0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.0; rv:68.0) Gecko/20100101 Thunderbird/68.12.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hello, On 2021-11-08 02:29, Maxim Boguk wrote: > On Sun, Nov 7, 2021 at 2:07 AM Andres Freund wrote: >> Hi, >> >> On November 4, 2021 1:01:44 PM PDT, Maxim Boguk wrote: >>> UPDATE: the problem base table entry which had erroneous toast data >>> definitely had been created during the REINDEX run of toast idx. >> Do you have any details about the transaction / application that inserted the data? > Well... jdbc with server side prepared statements off (pgbouncer). > I was told that application inserts rows into given table with queries like: INSERT INTO zz (id, body) VALUES (?, ?) ON CONFLICT (id) DO NOTHING inside transaction. It's possible to attempt to insert row with same id several times inside one transaction (in that case usually that id is new one i.e. was not presented in the table before that transaction). Hope it could help in some way. -- Thanks, Alexey Ermakov