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 1rQhoR-0033gl-MD for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Jan 2024 05:53:08 +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 1rQhoQ-007Ivr-Qm for pgsql-hackers@arkaria.postgresql.org; Fri, 19 Jan 2024 05:53:06 +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 1rQhoQ-007Ivj-FO for pgsql-hackers@lists.postgresql.org; Fri, 19 Jan 2024 05:53:06 +0000 Received: from mail-oa1-x30.google.com ([2001:4860:4864:20::30]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1rQhoN-002Gkc-Uq for pgsql-hackers@postgresql.org; Fri, 19 Jan 2024 05:53:05 +0000 Received: by mail-oa1-x30.google.com with SMTP id 586e51a60fabf-2046b2cd2d3so385985fac.0 for ; Thu, 18 Jan 2024 21:53:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1705643583; x=1706248383; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=k9S+T6M6MPqlBOQLkGclRqaIAS1/RIechDQqphuT6KQ=; b=MFSBx5QZFhbJjNrFS2ro4xxU6NDxscrLeXFFC8RcT2JC/owoy0JcnSH7T7RiZMr7dM 4nOCgvisab3ItXWa0OYFoEJrIYQ5uGXWbvOe2UwlniE9hU6rxV/5UOFjGh/xv4gAQMt0 qFiThRXFJMm9gUg4xgBkQYEK2ejqWwbUJQp8LGxq2+TlSWWfKu9vhaAOTJsucKSVe8CH wlTW4XZEpzh+F/6HTlsJhDhP73LaWVYEivlzOw/BDGe8AMgmKuKy5u7U+71pMKyK1QGy KlS8iCQrJ8FcKucTAKt4jp7GTTOecZKZPlE58airIsbVYrra9ivrbPjn56ygkH0lxEk0 3fIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1705643583; x=1706248383; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=k9S+T6M6MPqlBOQLkGclRqaIAS1/RIechDQqphuT6KQ=; b=UUN7z3iLQCxAaDNLVqqo7ucrutLYu8ghMfy24EFtsnPuixld91Qg9bvSEzzqKgxkMP bOxw70Tao3Ke2gzooNkN5HeW0xEd9+jRcXGNxylmGr5bSEHp66AfdNTf44a92MSlpcUR 3t/OLAtqkxkLtOqs9RuTAwWFB2+CylJdOVpWAwkE4kIi8xCBZuu8KZyy4Ggo4HzMnj8M HKB0NgzZThvm0wrJsIRiUSkLU7Jz4GM4Hn5x2XkyDripatAaah6tMk1lSYHx6VRPGVlE bsX7gp+ahJbHdNBUwHg2ugeUOZTOaSy3kYEXrZ2yPsq+LhC9T5RZ9pW69ZXWgjSARcr/ DcsA== X-Gm-Message-State: AOJu0Ywu62EYeLxCl3VcCRGagaWsX3YJogF3YNty8Aa6rLzBvOUbqFI5 4bC5qxtgO/DhTjIxsMl5P8aFSbBTZAJQU8cs6fhUcwaIyofkLXuHvl0QrTpck0+Qv/PEe496H2D Fiyin8ENGklIj2AtN5vuR/t/Cx/E= X-Google-Smtp-Source: AGHT+IGBKrotKXxiyMw2NviB1utHK9wU0x0Hc434QQLmra/fMPa3dWREZrWVERR352O7m++rKzyU4LBDgU1OTD1uKiE= X-Received: by 2002:a05:6870:a687:b0:210:bc4e:f0a7 with SMTP id i7-20020a056870a68700b00210bc4ef0a7mr2436757oam.10.1705643583022; Thu, 18 Jan 2024 21:53:03 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Amit Kapila Date: Fri, 19 Jan 2024 11:22:51 +0530 Message-ID: Subject: Re: Synchronizing slots from primary to standby To: shveta malik Cc: Bertrand Drouvot , Masahiko Sawada , "Zhijie Hou (Fujitsu)" , Dilip Kumar , Peter Smith , Nisha Moond , "Hayato Kuroda (Fujitsu)" , Bharath Rupireddy , Peter Eisentraut , Bruce Momjian , Ashutosh Sharma , Andres Freund , pgsql-hackers , Ajin Cherian , Alvaro Herrera Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Wed, Jan 17, 2024 at 4:06=E2=80=AFPM shveta malik wrote: > > > > > 5 =3D=3D=3D (coming from v62-0002) > > + Assert(tuplestore_tuple_count(res->tuplestore) =3D=3D 1); > > > > Is it even possible for the related query to not return only one row? (= I think the > > "count" ensures it). > > I think you are right. This assertion was added sometime back on the > basis of feedback on hackers. Let me review that again. I can consider > this comment in the next version. > OTOH, can't we keep the assert as it is but remove "=3D 1" from "count(*) =3D 1" in the query. There shouldn't be more than one slot with same name on the primary. Or, am I missing something? --=20 With Regards, Amit Kapila.