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 1nJFyd-0002Hc-Ma for pgsql-hackers@arkaria.postgresql.org; Sun, 13 Feb 2022 14:35:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nJFyc-0006PY-JY for pgsql-hackers@arkaria.postgresql.org; Sun, 13 Feb 2022 14:35:46 +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 1nJFyc-0006Oo-68 for pgsql-hackers@lists.postgresql.org; Sun, 13 Feb 2022 14:35:46 +0000 Received: from mail.postgrespro.ru ([93.174.131.139]) by makus.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nJFyZ-0003IF-90 for pgsql-hackers@lists.postgresql.org; Sun, 13 Feb 2022 14:35:45 +0000 Received: from falcon-note (cyclops.postgrespro.ru [93.174.131.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail.postgrespro.ru (Postfix) with ESMTPSA id F09FE21C0B84; Sun, 13 Feb 2022 17:35:40 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=postgrespro.ru; s=mail; t=1644762941; bh=5DDm06NfZJFPuVYVcEOvM6M2kwHTvYEXyOyXhhnAU3M=; h=Subject:From:To:Cc:Date:In-Reply-To:References; b=mt/Y1uoFP56zti3vUvO6ukl4R8B6ILBVUuJ1Eq6IMaT9lMZ9hWuuZmpn5naB4lJtQ UK46HywXf1sOkPUpYMOM+D5UZ0mcnvQm+20c9QscTQFE4YbEEVKpAGEbiaXB/yHptS 72xppHP2gpHEv8m6OjVOeC4Us1g7a1bRNN0OMW3w= Message-ID: <755c7bb23ad97a4a5319ebd13cdf8afccf5f05ed.camel@postgrespro.ru> Subject: Re: Error "initial slot snapshot too large" in create replication slot From: Yura Sokolov To: Dilip Kumar , Kyotaro Horiguchi Cc: Julien Rouhaud , PostgreSQL Hackers Date: Sun, 13 Feb 2022 17:35:38 +0300 In-Reply-To: References: <20220112103855.ib4455yyebaxkuwp@jrouhaud> <20220131.143158.896330709668373625.horikyota.ntt@gmail.com> <20220131.152011.148738317202375552.horikyota.ntt@gmail.com> Organization: PostgresPro Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.5-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk В Пн, 07/02/2022 в 13:52 +0530, Dilip Kumar пишет: > On Mon, Jan 31, 2022 at 11:50 AM Kyotaro Horiguchi > wrote: > > At Mon, 17 Jan 2022 09:27:14 +0530, Dilip Kumar wrote in > > > > me> Mmm. The size of the array cannot be larger than the numbers the > > me> *Connt() functions return. Thus we cannot attach the oversized array > > me> to ->subxip. (I don't recall clearly but that would lead to assertion > > me> failure somewhere..) > > > > Then, I fixed the v3 error and post v4. > > Yeah you are right, SetTransactionSnapshot() has that assertion. > Anyway after looking again it appears that > GetMaxSnapshotSubxidCount is the correct size because this is > PGPROC_MAX_CACHED_SUBXIDS +1, i.e. it considers top transactions as > well so we don't need to add them separately. > > > SnapBUildInitialSnapshot tries to store XIDS of both top and sub > > transactions into snapshot->xip array but the array is easily > > overflowed and CREATE_REPLICATOIN_SLOT command ends with an error. > > > > To fix this, this patch is doing the following things. > > > > - Use subxip array instead of xip array to allow us have larger array > > for xids. So the snapshot is marked as takenDuringRecovery, which > > is a kind of abuse but largely reduces the chance of getting > > "initial slot snapshot too large" error. > > Right. I think the patch looks fine to me. > Good day. I've looked to the patch. Personally I'd prefer dynamically resize xip array. But I think there is issue with upgrade if replica source is upgraded before destination, right? Concerning patch, I think more comments should be written about new usage case for `takenDuringRecovery`. May be this field should be renamed at all? And there are checks for `takenDuringRecovery` in `heapgetpage` and `heapam_scan_sample_next_tuple`. Are this checks affected by the change? Neither the preceding discussion nor commit message answer me. ------- regards Yura Sokolov Postgres Professional y.sokolov@postgrespro.ru funny.falcon@gmail.com