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 1sp57O-00GK8H-Q5 for pgsql-general@arkaria.postgresql.org; Fri, 13 Sep 2024 12:09:43 +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 1sp57O-0023cm-FV for pgsql-general@arkaria.postgresql.org; Fri, 13 Sep 2024 12:09:42 +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 1sp57O-0023cV-4M for pgsql-general@lists.postgresql.org; Fri, 13 Sep 2024 12:09:42 +0000 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1sp57H-000xah-IH for pgsql-general@postgresql.org; Fri, 13 Sep 2024 12:09:40 +0000 Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5bef295a45bso315873a12.0 for ; Fri, 13 Sep 2024 05:09:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1726229374; x=1726834174; darn=postgresql.org; h=to:subject:message-id:date:from:mime-version:from:to:cc:subject :date:message-id:reply-to; bh=5DhekVGNPJeSZnjwHU7i+UE9WXHgpQUKSrfQHWFIFU8=; b=Ggufs4dlfnb+5/DrvjDn47rEFdV5pkFhqHdowU0aULORaygvHnpU1rpiSGjPfFIEzS KnRlF3F6mTooG1RZWrFkJc3MFgwIc6YdUPcdM255ti/Xdrk/WgXpJBJz8oMM0IZLgb4v VrdLmGaH/oLO0blCRzuvn41Jn0N0T5TKewyBV1QeFlv6/ojlm+wJbnPyPYuv94stNAr4 s+WMNjgcEJxcBc2nlbVvGmmdnQ4GGEZXhGga+qerdalyuppxHBCGxkduuLz4DAJnaf7U mMCXudN9ywX8wZ9nCw4O1SlHw+2HGohjqcg9DNbhkOvQ7U8rKoMzQHQKCFkS13n2d6s5 3Qcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1726229374; x=1726834174; h=to:subject:message-id:date:from:mime-version:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=5DhekVGNPJeSZnjwHU7i+UE9WXHgpQUKSrfQHWFIFU8=; b=w14kx4o48T0Cm+025PmEIGBzwTx0eOjh+YZExqn7dn1V5Pv1fbJFf9nqHJev1b4K4+ k+EsypSrG4yDWFFmRN4tmYeLKgzoW/WcN3ZPZ8X/S/xjYIlkzDbDYU/zex53EPv8ATFt V5y+j57vxCc+0zKhW2e61XHquMWHG3v3lAAhn76s4jBcINi7FAgaUlf2fcYH4xcAevwg J3VipkX/vpPh0Z2+ZnZItIqFr5cHmH5rbufnbjjHsX8NAEQQoFtjZVSBLDukl6zrInzY 4UPuSmyriI3Ldo2lVg4zR9irq6v7O55fSrl2WF9w9/M83j/udLQLR0/9ZVE+WisVHMAD vW3g== X-Gm-Message-State: AOJu0Yw6Z4Xmk4eLQXRcYwzn/JG1nQJOhZG36MrJe6k4cRnk2gRQKZvq NO37R4HPEgwD7unys6eNc13pPJFih51XV6VwUreefqX4X8pQytzKTyZQwdiui71qFI4fqE/1GG6 I4Tp0oOfcTC/V8DfboEtpluTAdIj6MQ== X-Google-Smtp-Source: AGHT+IG3QJIt0EkTXHm6qM3Ea8EY3U3y13erDm+b9kIyGjUM3I0ad7bpItw96HrQku4WLA7n5kLms9pfFmRlmwGD8xg= X-Received: by 2002:a05:6402:280f:b0:5c3:cb45:2e with SMTP id 4fb4d7f45d1cf-5c41dea6c46mr2809933a12.5.1726229373891; Fri, 13 Sep 2024 05:09:33 -0700 (PDT) MIME-Version: 1.0 From: Vinay Oli Date: Fri, 13 Sep 2024 17:39:22 +0530 Message-ID: Subject: Reg: Size difference To: pgsql-general@postgresql.org Content-Type: multipart/alternative; boundary="000000000000a1bbd50621ff18cf" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000a1bbd50621ff18cf 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 --000000000000a1bbd50621ff18cf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Hi Team

<= p>

I have been using PostgreSQL for the past 6 years. PostgreSQL has = significantly impacted my life, providing me with great opportunities for k= nowledge and self-development.

I'm currently facing a stra= nge issue with PostgreSQL 15.0. I have a primary-standby setup that is in s= ync, with a replication slot in place. There are 18 databases, and one of t= he 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.

Coul= d this be a bug? If so, has it been resolved in newer releases? If it is no= t a bug, how can this issue be fixed? Is there a solution or any supporting= documentation available?

WAL and log files are being rotated properl= y. 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 216G= B, 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


--000000000000a1bbd50621ff18cf--