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 1nEPIN-0005if-P4 for pgsql-hackers@arkaria.postgresql.org; Mon, 31 Jan 2022 05:32: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 1nEPIM-0008Sv-H6 for pgsql-hackers@arkaria.postgresql.org; Mon, 31 Jan 2022 05:32:06 +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 1nEPIM-0008Sm-83 for pgsql-hackers@lists.postgresql.org; Mon, 31 Jan 2022 05:32:06 +0000 Received: from mail-pl1-x631.google.com ([2607:f8b0:4864:20::631]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1nEPIH-0001dh-NQ for pgsql-hackers@lists.postgresql.org; Mon, 31 Jan 2022 05:32:05 +0000 Received: by mail-pl1-x631.google.com with SMTP id d18so11506901plg.2 for ; Sun, 30 Jan 2022 21:32:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:message-id:to:cc:subject:from:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=vTyWBIMOOBILaORoXft6tfP159ru8Of3IkEhjUr3ixQ=; b=lQw0D2sUXKKSIulqO0Io6kIe4oWTYUYX/W68u30YIZooUI4mIkfXo6dPyyzihO2qMs ISgm+C5/JOwO5pWU3lXm1TQt5YZ/YwLGccszetkTpBEQ15lwsVrF88T25WLkwLt1oKsm Wh/AUdHPVFNF9kbsTtvzWsui/KTVyVwaaU568qWOyWYD3w6dO0Rj/B0J1ut48mM2ZtjA 5FyfQTpd4HVuw2cY3Yn34+KnHquqWMkNJbp8qH6GtWY5f00m7t87hJrx/cvgJ6y6sine 3XifhIbiYDKeqaS9N+1ecSYVeanFPOfo1uw+bxp3Ltrqq9AC53uOsA9oom7W1qq3fkwG 5tUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:message-id:to:cc:subject:from:in-reply-to :references:user-agent:mime-version:content-transfer-encoding; bh=vTyWBIMOOBILaORoXft6tfP159ru8Of3IkEhjUr3ixQ=; b=QVM+deYJlhp431z64IL0su0NPeRD3m/JCIirltSTJ5CdLmxVXJQZF+rNntGtjQYzSS e8Jt0qDPc31OhAqEoP5+XNqQZd70P6inI32f4kifa6LXWQtZpUoFlJsVM7wxDhNsiEos LStsPAYrrgJ1OmR0d/MuL9hMAVU6v8yjycBAU5iWbs7CZmj6ipDU+/QsKxJvyQqU3MJi uDnJthZoDrZobo0vXIVeHoyoo4WDxuunKS7amCg4iNI6O0xxL2xDUaU42VMUIl0rVCGI PCNE6kZNVMXjDbxbk1gbe3WWOXzZeO7pJJ1KtvRjztENpuKTGDB/H8fDKCzbTKqOwPoh ERbg== X-Gm-Message-State: AOAM531RpovWkGdYujYLDfp5h0wDjz688lg9Kb5AxACYuLQmh+OMOE9Z zRgd/BvR9+Pqd4hZhTTs6O8= X-Google-Smtp-Source: ABdhPJx4UN89t1vlGM0ndSsf7aSngS/DvrV9TAGZW9omHmjT3RO4T7uf4nRtTgPVHRkGK8VR3taIrg== X-Received: by 2002:a17:902:ce84:: with SMTP id f4mr18601198plg.140.1643607120793; Sun, 30 Jan 2022 21:32:00 -0800 (PST) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id g22sm13191073pfc.177.2022.01.30.21.31.59 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Sun, 30 Jan 2022 21:32:00 -0800 (PST) Date: Mon, 31 Jan 2022 14:31:58 +0900 (JST) Message-Id: <20220131.143158.896330709668373625.horikyota.ntt@gmail.com> To: dilipbalaut@gmail.com Cc: pgsql-hackers@lists.postgresql.org Subject: Re: Error "initial slot snapshot too large" in create replication slot From: Kyotaro Horiguchi In-Reply-To: References: User-Agent: Mew version 6.8 on Emacs 26.1 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk At Tue, 2 Nov 2021 16:40:39 +0530, Dilip Kumar wrote in > On Tue, Oct 19, 2021 at 2:25 PM Dilip Kumar wrote: > > > > On Tue, Oct 12, 2021 at 11:30 AM Dilip Kumar wrote: > > > > > > On Tue, Oct 12, 2021 at 10:35 AM Kyotaro Horiguchi > > > wrote: > > > > > > > > At Tue, 12 Oct 2021 13:59:59 +0900 (JST), Kyotaro Horiguchi wrote in > > > > > So I came up with the attached version. > > > > > > > > Sorry, it was losing a piece of change. > > > > > > Yeah, at a high level this is on the idea I have in mind, I will do a > > > detailed review in a day or two. Thanks for working on this. > > > > While doing the detailed review, I think there are a couple of > > problems with the patch, the main problem of storing all the xid in > > the snap->subxip is that once we mark the snapshot overflown then the > > XidInMVCCSnapshot, will not search the subxip array, instead it will > > fetch the topXid and search in the snap->xip array. > > I missed that you are marking the snapshot as takenDuringRecovery so > your fix looks fine. > > Another issue is > > that the total xids could be GetMaxSnapshotSubxidCount() > > +GetMaxSnapshotXidCount(). > > > > I have fixed this, the updated patch is attached. Mmm. The size of the array cannot be larger than the numbers the *Connt() functions return. Thus we cannot attach the oversized array to ->subxip. (I don't recall clearly but that would lead to assertion failure somewhere..) regards. -- Kyotaro Horiguchi NTT Open Source Software Center