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.94.2) (envelope-from ) id 1sLknl-00GNdX-GZ for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Jun 2024 14:36:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1sLknj-009omr-TL for pgsql-hackers@arkaria.postgresql.org; Mon, 24 Jun 2024 14:36:12 +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.94.2) (envelope-from ) id 1sLknj-009omj-JN for pgsql-hackers@lists.postgresql.org; Mon, 24 Jun 2024 14:36:11 +0000 Received: from mail-lj1-x235.google.com ([2a00:1450:4864:20::235]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sLknf-002ts4-KQ for pgsql-hackers@lists.postgresql.org; Mon, 24 Jun 2024 14:36:10 +0000 Received: by mail-lj1-x235.google.com with SMTP id 38308e7fff4ca-2eabd22d3f4so54460631fa.1 for ; Mon, 24 Jun 2024 07:36:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1719239765; x=1719844565; darn=lists.postgresql.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=s6YF/eURAO/MNN07PvZUtvYSGyGgOI2bhFXydCZjJ9s=; b=XyXtnimC3E1IMbotmPMoGZBUb5wDZyLFVZEOUZIPgDar8dAMmyIrSBz1jipNFAvQGc eueMfyxIUd44IE3bwGcFpvDcDkBvGichLsy3Rd/enSbFKi0YnrcUQzKhn+mQAjwKgSQl Dux3qI6x2fTgheOTJiJZnR3GupvAbWV54d8jB3MWlnouvYdQCmVc3yW9mNz4UqZuD1tS gZShcke31sY9rKUS09bDeXGPaasXNSS8dz2x1C+gehoim3H7jhO90AE1Ek4kpLtyccIa OZBNWg2b3060M0mXMaz/Rs66euMqn3DZHwkfp8Jnn5YfQWJYyozTGJitcbn9zbnUiCZf Ww+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719239765; x=1719844565; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=s6YF/eURAO/MNN07PvZUtvYSGyGgOI2bhFXydCZjJ9s=; b=peyFxKWA6N2A1avyCqxdShg5N0SH6oATxNyzcNpMXGmbsYkSFsjjHtrSfGgby0elET 5FLXjtjUyNrwSupg3Puo8EqGFPFVduJgIrd9CfNw7EEgIfyzDaU6SaFyg985Tk7qX5pL 8xiBKoPIi4+RVpwWYGM6n9L4dgVREb7TGs1HTzGU7OHD//SyRD+HzlKZcoyDPkSg4ugK MP3xOEIbUexuFfqDIPzvtTT5OJFAP2T4kFN5oHYH89NHfHWfrFW7p2ENgoJfV2gf73Zp WjcmBNFdVenupOggF0cjqz0NaB7fKQKgN9DT8I37A7vV/2D4JkSqvCc1WDBCy2pxpWMe tGDg== X-Gm-Message-State: AOJu0YwH71w2m7rtsVzYVM26faBTCfDlvZR/eKH/LsxP7S8gu9jce0Kk shmZ670B8rq+0Lp6Q/O1K12dwDp4HMk22FCvcY4Z0SQukkWsGeN3DbZXjPH3IQ== X-Google-Smtp-Source: AGHT+IGMF4JO2Mnv7Vb1k+opjIsUu98f+IKfDbW76yUKfPCHptwFPsQAbMH7ypF8E6QcPg1Xm+CfNA== X-Received: by 2002:a2e:b046:0:b0:2ec:4d98:c9d6 with SMTP id 38308e7fff4ca-2ec5b2b1d23mr26075331fa.29.1719239764999; Mon, 24 Jun 2024 07:36:04 -0700 (PDT) Received: from [10.137.0.18] (srv1.mobissw.com. [89.235.0.226]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-57d30535115sm4802003a12.78.2024.06.24.07.36.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 24 Jun 2024 07:36:04 -0700 (PDT) Message-ID: <571f7387-edfa-4733-a335-ccce7ce01574@enterprisedb.com> Date: Mon, 24 Jun 2024 16:36:04 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: long-standing data loss bug in initial sync of logical replication To: Amit Kapila , Andres Freund Cc: PostgreSQL Hackers References: <20231118015443.sfxfbr4eqolxbmjc@awork3.anarazel.de> <20231118025445.crhaeeuvoe2g5dv6@awork3.anarazel.de> <49958b83-009a-9360-2969-ea42cd15fff7@enterprisedb.com> <20231118181257.qtebsnkrzj3icg36@awork3.anarazel.de> <3c5ad91c-330a-0c5a-974a-da3801ffc18b@enterprisedb.com> <20231118210519.yborkczu2aln6zdd@awork3.anarazel.de> <5cc4bbc8-b2ad-3e6e-9878-cef8ddde8ffe@enterprisedb.com> <20231119021830.d6t6aaxtrkpn743y@awork3.anarazel.de> Content-Language: en-US From: Tomas Vondra In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 6/24/24 12:54, Amit Kapila wrote: > ... >> >>>> I'm not sure there are any cases where using SRE instead of AE would cause >>>> problems for logical decoding, but it seems very hard to prove. I'd be very >>>> surprised if just using SRE would not lead to corrupted cache contents in some >>>> situations. The cases where a lower lock level is ok are ones where we just >>>> don't care that the cache is coherent in that moment. >> >>> Are you saying it might break cases that are not corrupted now? How >>> could obtaining a stronger lock have such effect? >> >> No, I mean that I don't know if using SRE instead of AE would have negative >> consequences for logical decoding. I.e. whether, from a logical decoding POV, >> it'd suffice to increase the lock level to just SRE instead of AE. >> >> Since I don't see how it'd be correct otherwise, it's kind of a moot question. >> > > We lost track of this thread and the bug is still open. IIUC, the > conclusion is to use SRE in OpenTableList() to fix the reported issue. > Andres, Tomas, please let me know if my understanding is wrong, > otherwise, let's proceed and fix this issue. > It's in the commitfest [https://commitfest.postgresql.org/48/4766/] so I don't think we 'lost track' of it, but it's true we haven't done much progress recently. regards -- Tomas Vondra EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company