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 1oY1K5-0005pv-Te for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Sep 2022 08:31:13 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1oY1K4-0008OI-NO for pgsql-hackers@arkaria.postgresql.org; Tue, 13 Sep 2022 08:31:12 +0000 Received: from makus.postgresql.org ([72.32.157.229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oY1K4-0008O9-EM for pgsql-hackers@lists.postgresql.org; Tue, 13 Sep 2022 08:31:12 +0000 Received: from mail-pg1-x52e.google.com ([2607:f8b0:4864:20::52e]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1oY1K2-0001cO-AE for pgsql-hackers@lists.postgresql.org; Tue, 13 Sep 2022 08:31:11 +0000 Received: by mail-pg1-x52e.google.com with SMTP id bh13so10665519pgb.4 for ; Tue, 13 Sep 2022 01:31:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:from:subject:cc:to:message-id:date:from:to:cc:subject :date; bh=85p+nFMHeanR8x51+CU1tPChYwUS88bO2V9rmLZDP5U=; b=q6S6qPAi3bNHHZyyhUGv9B1xSVmRV4WRzlQK6EMs+0VbKzoNepb+f2PG1L6T28+/sx vnNruQgfIUkhzy1A1dOQPGunTLtTm4GKuzs5+ScrpsSlgTuhQGCGcvL6PxV1+C028Cmq yZ84c9gHf1WXb1eyjX4c9AQeXiGbQVxlIhIAKcbta7jEUe52swo9hXI62xZOnFzWLTnj aMD4V/IfkcaPDeALI+tRrTrXR+XVKKQdMguzjDQ8ASGR9Xbu/QO2A8tOdJcmyfPOdAd9 nN6GWPorS4tpcJi/pBDLk3elv1jIv9d6nUAngnZ270AE5Q/xUM3lYSWEEPvhKOwvSY6E grag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:references :in-reply-to:from:subject:cc:to:message-id:date:x-gm-message-state :from:to:cc:subject:date; bh=85p+nFMHeanR8x51+CU1tPChYwUS88bO2V9rmLZDP5U=; b=KD35GDEL88yuWZ6yOyhmVs0is3HVZf40wH0hQi+GPpJ33yIIP3OG2i7hFrTsvehlim h6X/ozddId0rrqY6YxSltpnJeH2u4X3BZNk57O/kFRFNqFKWYTEg3dIYDWHsxO7UGEaY 8bR+9v86+uRDxEgXORp6UgS2o0ELPy/HNSsqTNtr6yH23+LT74JQOFd7mNrSIiaUAgIG kth/R7OjGB5TzvdVe4JHyZnnq5zXxYlXcUGPVtwbMtljSc8Md0LVsWxmeImiN8E0hFbR RPr4nL4mvTNq5IjDmcT4jHJ0wt/limk0rSGNpzlBmp5EVoVlcAKAt0OOGICGFWq17Pz1 ANGw== X-Gm-Message-State: ACgBeo3T9tNS12jDdvGivGRPZaZVqhdBdOthjfJd0oLZAtdUtmItYG24 V9e0U/JirHhRbRWrserwwNQ= X-Google-Smtp-Source: AA6agR7SUB+nJ0JI3jVCnFzMi5lEpzPKY2QPEyVuEO5G1qigSgJNtur03CSnmms4lcnUq96BqsSP9w== X-Received: by 2002:a63:594c:0:b0:438:f2ce:8780 with SMTP id j12-20020a63594c000000b00438f2ce8780mr8372109pgm.285.1663057868909; Tue, 13 Sep 2022 01:31:08 -0700 (PDT) Received: from localhost (KD036014041111.ppp-bb.dion.ne.jp. [36.14.41.111]) by smtp.gmail.com with ESMTPSA id z189-20020a6233c6000000b0054087e1aea4sm7387148pfz.15.2022.09.13.01.31.06 (version=TLS1_3 cipher=TLS_CHACHA20_POLY1305_SHA256 bits=256/256); Tue, 13 Sep 2022 01:31:08 -0700 (PDT) Date: Tue, 13 Sep 2022 17:31:05 +0900 (JST) Message-Id: <20220913.173105.1366509818461708829.horikyota.ntt@gmail.com> To: andres@anarazel.de Cc: jchampion@timescale.com, y.sokolov@postgrespro.ru, dilipbalaut@gmail.com, rjuju123@gmail.com, pgsql-hackers@lists.postgresql.org Subject: Re: Error "initial slot snapshot too large" in create replication slot From: Kyotaro Horiguchi In-Reply-To: <20220913.161534.1763577367544098635.horikyota.ntt@gmail.com> References: <20220912215156.zi52zu6n7od3k3v3@awork3.anarazel.de> <20220913.154507.1031550660908356731.horikyota.ntt@gmail.com> <20220913.161534.1763577367544098635.horikyota.ntt@gmail.com> 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, 13 Sep 2022 16:15:34 +0900 (JST), Kyotaro Horiguchi wrote in > At Tue, 13 Sep 2022 15:45:07 +0900 (JST), Kyotaro Horiguchi wrote in > > At Mon, 12 Sep 2022 14:51:56 -0700, Andres Freund wrote in > > > This sees a tad misleading - the previous snapshot wasn't borken, right? > > > > I saw it kind of broken that ->xip contains sub transactions. But I > > didn't meant it's broken by "correct". Is "proper" suitable there? > > No. It's not broken if it is takenDuringRecovery. So this flag can be > used to notify that xip can be oversized. > > I realized that rbtxn_is_known_subxact is not reliable. I'm > redirecting to oversized xip. Pleas wait for a while. However, the reader of saved snapshots (ImportSnapshot) has the restriction that > if (xcnt < 0 || xcnt > GetMaxSnapshotXidCount()) > ereport(ERROR, and > if (xcnt < 0 || xcnt > GetMaxSnapshotSubxidCount()) > ereport(ERROR, (this xid is subxcnt) And ExportSnapshot repalces oversized subxip with overflowed. So even when GetSnapshotData() returns a snapshot with oversized subxip, it is saved as just "overflowed" on exporting. I don't think this is the expected behavior since such (no xip and overflowed) snapshot no longer works. On the other hand, it seems to me that snapbuild doesn't like takenDuringRecovery snapshots. So snapshot needs additional flag signals that xip is oversized and all xid are holded there. And also need to let takenDuringRecovery suggest subxip is oversized. regards. -- Kyotaro Horiguchi NTT Open Source Software Center