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 1spWQd-0025Qv-My for pgsql-general@arkaria.postgresql.org; Sat, 14 Sep 2024 17:19:24 +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 1spWQd-0002G9-3j for pgsql-general@arkaria.postgresql.org; Sat, 14 Sep 2024 17:19:23 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1spWQc-0002Fy-JM for pgsql-general@lists.postgresql.org; Sat, 14 Sep 2024 17:19:22 +0000 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1spWQY-001BLg-R6 for pgsql-general@postgresql.org; Sat, 14 Sep 2024 17:19:21 +0000 Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5c24c92f699so3062487a12.2 for ; Sat, 14 Sep 2024 10:19:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726334359; x=1726939159; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=tioR7Uty9wvfQx7TWebYr7s3ecY81WzaUKH4WD23NUE=; b=DztU2SXqUZOrdUcwlDgk8nhR9BM013xgaA/Bk7CO1CXCh4G9iLebHGQoTHsuaQ9wIp ay0UixieTtiQNBOXxetgdoQjiQ9wHbgDsTze9CgXWoQ7bW2dRsGNWUbuQyo+xrD9ZuX0 DmZhYfJEckMxuM55ytb5K5thPDHDmdbDNGqgKm4p4Ln1BolFtkI0jt2vxGe5NA3vvWql qV381dMacddAQDavVdbdkIDL1KURM000bPkyC+EMu8haSYw4lQTJHDvI4FaeMgiiHEwI FgFdSKhLZ+LoL7ASiUYq5DaeYjyCeuEnlMQYHC7ZWPHokpYoH208vO99OlVjV/VhYwkq m8yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726334359; x=1726939159; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=tioR7Uty9wvfQx7TWebYr7s3ecY81WzaUKH4WD23NUE=; b=cmSyrKf4rVU6HKWHlO3Gs4KThUu0SvbV1OoshWQGccczeDwZn2RyBftfXr4EHWH6bI VCcMCiqBKi92GeAWOpusujRVDwgPRupBIFKlsze7FGiqGzT14MNkl7VQFM5uzS+nY2uH cTbP20e9AmAZ4frU5X/2qGzN0tLFoEhCgffqLl7u3kEej3qNOLKljhtNdw7Ykrec7Hsh 9gBHvMHcBqwFfs6EYlkbwBNaGVLSujSp1IljRuvIlE5O2dtUfy0PRZyMXmceYm6S6HQn SB782FwWSoFauwvHUG6IAjo9oxxliS5pPvoLAP4SUZ4ijZItST0jOEOh1inQCRAS43Td u/hw== X-Gm-Message-State: AOJu0YxJXI3dljZdTZanmz4HJQEBzCMtNIlJKLosauHcZSgZVZIpqdg1 g7AoEidelPS1cwZQMnBkRjCgktF1imr3hqkLRz5HGTpPC/uTtmdNfbO0EsgfxMRXFBPZXjRoJhz coqCEC032SaWOpRW+g6gLiQjSkB5tYw== X-Google-Smtp-Source: AGHT+IEvHkGNdxPCsnVQkF0sKeBXOSWZtvcAWkzBh44Ra0ZgFlNCu9u+KSOGUBhq/r4kwDAn/7qaPR2VKq07Ob2mmYM= X-Received: by 2002:a05:6402:5106:b0:5c2:4cbe:ac33 with SMTP id 4fb4d7f45d1cf-5c413e0607amr8549391a12.2.1726334358465; Sat, 14 Sep 2024 10:19:18 -0700 (PDT) MIME-Version: 1.0 From: Vinay Oli Date: Sat, 14 Sep 2024 22:49:07 +0530 Message-ID: Subject: Reg: Size difference To: pgsql-general@postgresql.org Content-Type: multipart/alternative; boundary="0000000000003334a50622178a23" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003334a50622178a23 Content-Type: text/plain; charset="UTF-8" Hi Team I have been using PostgreSQL for the past 6 years. PostgreSQL has significantly impacted my life, providing me with great opportunities for knowledge and self-development. I'm currently facing a strange issue with PostgreSQL 15.0. I have a primary-standby setup that is in sync, with a replication slot in place. There are 18 databases, and one of the databases on the primary side is 104 GB, while the same database on the standby side is 216 GB. Both are in sync with zero delay. Could this be a bug? If so, has it been resolved in newer releases? If it is not a bug, how can this issue be fixed? Is there a solution or any supporting documentation available? WAL and log files are being rotated properly. The issue is with a database named services_mfs. On the primary cluster, the services_mfs database is 104GB, but on the standby cluster, it is 216GB, even though both cluster are in sync. The standby database is only used in case of a crash, which is managed by a Patroni cluster with etcd. Thanks, Vinay Kumar --0000000000003334a50622178a23 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Team

I have been using PostgreSQL for the past 6 years. Po= stgreSQL has significantly impacted my life, providing me with great opport= unities for knowledge and self-development.

I'm currently = facing a strange issue with PostgreSQL 15.0. I have a primary-standby setup= that is in sync, with a replication slot in place. There are 18 databases,= and one of the databases on the primary side is 104 GB, while the same dat= abase on the standby side is 216 GB. Both are in sync with zero delay.

<= p>

Could this be a bug? If so, has it been resolved in newer releases= ? If it is not a bug, how can this issue be fixed? Is there a solution or a= ny supporting documentation available?

WAL and log files are being ro= tated properly. The issue is with a database named services_mfs. On the pri= mary cluster, the services_mfs database is 104GB, but on the standby cluste= r, it is 216GB, even though both cluster are in sync. The standby database = is only used in case of a crash, which is managed by a Patroni cluster with= etcd.



Thanks,

Vinay Kumar



--0000000000003334a50622178a23--