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 1oXulX-0003mS-5E for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Sep 2022 01:31:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oXulV-0000oC-Ks for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Sep 2022 01:31:05 +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 1oXulV-0000o2-9m for pgsql-hackers@lists.postgresql.org; Tue, 13 Sep 2022 01:31:05 +0000 Received: from mail-oa1-x36.google.com ([2001:4860:4864:20::36]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oXulR-0006Ey-4B for pgsql-hackers@lists.postgresql.org; Tue, 13 Sep 2022 01:31:04 +0000 Received: by mail-oa1-x36.google.com with SMTP id 586e51a60fabf-1278624b7c4so28253336fac.5 for ; Mon, 12 Sep 2022 18:31:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=WJSFavVp+DyVJOKGyQTWcght3hWI+cBX7s2rcYtdn3g=; b=XVp5jRXakcJqn5a16Nve0CvsinKz6A+cpB4CFYP5tN6oFDdIn+UtcLgjVRd8xyYkJQ VuOqEM/Q7es3Rv0SLd0o21WKCth4Z9Hw87gDSSNrIuRFaQUKuSaYfZf2jdDunX7L562m 23Es/V6KvJVLNcKtZMgqvS8Jiqd+hO5Kio099IWOcGqobUUsYXPbaf3/E01jQaARc8y8 zyGmFQLgjqy4/JtgRig2M+9VH52feE//WE/u3u0NHLUmo/HX2qhDaIPnFxixHSgYign8 nwc98UvHh9i9YCoovk/pAYC7/6bbDKi82lgznr6IYlHUTEwt7Nh+1RXNdLUJHSgamIJT 93yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=WJSFavVp+DyVJOKGyQTWcght3hWI+cBX7s2rcYtdn3g=; b=EWlX6XtljG1iM6px0Hi9kWw5+qxeW9hpwNoFJ2gIkJeYTPmpbs9S2HUMwE3PVesw25 YdYsPFU/SRq6ME0dQVES710e4z6nHnyOhpbVZuyFfOD0XhaUBa2kS17DmH84n6uIY27C 0ovO/TjB4cG2eEANj77inrHXHj4QNFGgg0VIQVxUeNRD0xKOEMvm/9ls5bBhXJ4mzhGV lxKyj7IYDb/qG8U6StLqQcrkTejCygOmjaLm7onveD9xGxfFxIkQndnAE/eV3C3bO/T7 cu4mqOkpP/pRRvNzYeHrL4h2UyXnCtAoKMlQIRVh6G2cWWFIiW7k+ymCQa1+Ss5d7HhW e+YQ== X-Gm-Message-State: ACgBeo0LFFVTC92riM1+0qo8OX/gH33ijXQXQ0iaZSoALo2ZOMNk5a+O HI1+XDPKRshw6YPp/rdY0mf4Gtzqw2UWlvjgA+8= X-Google-Smtp-Source: AA6agR4cuTD+of7rhejYcWnivHoo29FFrVAAgcU0y+kvdCrWT5eP4d7JLubfmJlH1Cd8N3m5Myi/eQI8r+qbPL7wveM= X-Received: by 2002:a05:6870:218e:b0:126:9dc3:9666 with SMTP id l14-20020a056870218e00b001269dc39666mr582773oae.73.1663032658919; Mon, 12 Sep 2022 18:30:58 -0700 (PDT) MIME-Version: 1.0 References: <20220401.144430.1701887207072649814.horikyota.ntt@gmail.com> <20220401.155316.930989254339879136.horikyota.ntt@gmail.com> <20220719.115506.1518451006264600540.horikyota.ntt@gmail.com> <20220912215156.zi52zu6n7od3k3v3@awork3.anarazel.de> In-Reply-To: <20220912215156.zi52zu6n7od3k3v3@awork3.anarazel.de> From: Dilip Kumar Date: Tue, 13 Sep 2022 07:00:42 +0530 Message-ID: Subject: Re: Error "initial slot snapshot too large" in create replication slot To: Andres Freund Cc: Kyotaro Horiguchi , jchampion@timescale.com, y.sokolov@postgrespro.ru, rjuju123@gmail.com, pgsql-hackers@lists.postgresql.org Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Tue, Sep 13, 2022 at 3:22 AM Andres Freund wrote: > > It's not obvious to me that it's the right design (or even correct) to ask > reorderbuffer about an xid being a subxid. Maybe I'm missing something, but > why would reorderbuffer even be guaranteed to know about all these subxids? Yeah, you are right, the reorderbuffer will only know about the transaction for which changes got added to the reorder buffer. So this seems not to be the right design idea. > > I wonder if a better fix here wouldn't be to allow importing a snapshot with a > larger ->xid array. Yes, we can't do that in CurrentSnapshotData, but IIRC we > need to be in a transactional snapshot anyway, which is copied anyway? Yeah when I first found this issue, I thought that should be the solution. But later it went in a different direction. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com