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.96) (envelope-from ) id 1vV2z4-00CXb6-2v for pgsql-admin@arkaria.postgresql.org; Mon, 15 Dec 2025 07:27:07 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vV2z3-00GEk9-20 for pgsql-admin@arkaria.postgresql.org; Mon, 15 Dec 2025 07:27:06 +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.96) (envelope-from ) id 1vV2z3-00GEk0-0h for pgsql-admin@lists.postgresql.org; Mon, 15 Dec 2025 07:27:06 +0000 Received: from mail-ej1-x62a.google.com ([2a00:1450:4864:20::62a]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vV2z1-000opZ-23 for pgsql-admin@postgresql.org; Mon, 15 Dec 2025 07:27:05 +0000 Received: by mail-ej1-x62a.google.com with SMTP id a640c23a62f3a-b7ce5d6627dso9999766b.2 for ; Sun, 14 Dec 2025 23:27:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1765783617; x=1766388417; darn=postgresql.org; h=mime-version:content-language:accept-language:in-reply-to :references:message-id:date:thread-index:thread-topic:subject:to :from:from:to:cc:subject:date:message-id:reply-to; bh=3FgzW9JhAdOmI+fV9oMgc4xnzXbsHz52U8SjoWkI3QM=; b=Wjfzn2RVzGKjhuqsF91EmqoNivF+9ESBFdOlbnxIwCo7A8AKE/79h470+Zuj23uOFn FvTmSxnC6V7NNpHGrGCRw0Vbc694MLcyHqSsdLPF/AW5YLW6W973+W8F/ax6I1FCMsA5 dxU6WoA+epjdbt3xVa/XCWo7w/zvhL5uPeUNgnwSdI4g2/Vjm8zzQjJoCl5xZh3vaZAI stM8D4HUAITTNfiVk5PrUzCN2VMkoALYxLHMuYSakqVYkLgeN1rvCIzz3gNnTi+piKN8 P26NvS9uEyELhRoHlKbhDKOWZ1FCy5m1TLCC/X8rSicj+qiYnbMD+KeE6xVE2Pdj+JMP AnJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1765783617; x=1766388417; h=mime-version:content-language:accept-language:in-reply-to :references:message-id:date:thread-index:thread-topic:subject:to :from:x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=3FgzW9JhAdOmI+fV9oMgc4xnzXbsHz52U8SjoWkI3QM=; b=JCFmX2YA9Zs25aI0Ul0T5bWAms+8T2emiRiu9jVeHW1My8xQPOYTI7lZba3czOwkU4 YlCgBrDV0MEYED1rZdbLjbXvSzsDJA4aDUOOU5cUcFsZI5d/xVBod6x083GNpijLDIO8 zcYNsGffAiuT/gRV6ZANdNYXgFHA9QfANe7takNMZxF8vnI8AFO0xSXj2qxPthonOMbH j+qweUwC9H8wS140Y39LfJ/5dSFuTqTRy/84YBEvVAnzL2fdKOhDIwVfdk7KNitB7inS HiFU2MVGo8lycHvs2Nx7YMb2Zn6zajCEdV3s/BsnB4uTfstxqEQqS7fmAEgja4e1b4hq NrfA== X-Forwarded-Encrypted: i=1; AJvYcCX6CNXgUjZq9SmOx6jAYBqD19B37Az3+kcnlNQCr2cRAy5G5jHtd75AZuPKNZG3f+4yckNHnfghQS49ng==@postgresql.org X-Gm-Message-State: AOJu0YyX2vCnJ5W61al09xX2XebEwKSItp5AuN+D6W8umJwrKG8TuVJp b5VbGbHwf1scxXtE4lRnREONuQajWW/8qCUDT9otXdT9dYYUqpbo3p4q X-Gm-Gg: AY/fxX4JOVFQ+VfkqKEZ1SBlhcSnqrKEb1bwU6lWhOJC/Az3XZ3B2QrKDgvZ5Xg+/yq 8xqnnNwp3jHwzfPZPG3LtGMshLy2Kzj+2STqeKhhq7+MowW+hi10uV0b8KFyvWWK2+m/0rOruJv oSniCDAIUgQMTIOQimsJs2gfW6wg39lehjlHFGrF8TjLYCRrl1DRZqO9Wny/iZioSy+Ci8Ud1ws pdVkvWE0Rq7SVkPfrUrnt2eBtI4A2xdZfsOgtq1wFU2tkvU9wVWPiESiH8FP21i63tpXNmx7U54 umSUyW4Fk22zu0LDAL7txdfrfmDW6TGSmJWeOupzSde5zYyWi0FqVo4f7HkhAB3Qslm3bFRvJef 0Iob+SW1mOWXCvWOPuUT4zph0BnnEtmGY2nrLj+YOMefAI19cMs7r2qsK+7qXtGwq/ecmTXI/Ww C+YTKzLAVDqiB83yez+IQY3DHMQakMU7Bx35i+001yoGA0rROMvzvfAukelhope3uYLo0c3X4= X-Google-Smtp-Source: AGHT+IHlDGEjlJyMTRMT4GWXydvJYPBDOrYl0bteo/DQ6IAl++/wxOiv9N/SgToZOKiOSU1CQsFeig== X-Received: by 2002:a17:906:6a0e:b0:b73:51f3:a806 with SMTP id a640c23a62f3a-b7d23b14f8dmr1050144866b.51.1765783616535; Sun, 14 Dec 2025 23:26:56 -0800 (PST) Received: from AM4P193MB2941.EURP193.PROD.OUTLOOK.COM ([2603:1026:c03:8c0e::5]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-b7cfa5c8546sm1331846766b.65.2025.12.14.23.26.55 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Dec 2025 23:26:56 -0800 (PST) From: kasem adel To: Laurenz Albe , pgsql-admin Subject: Re: Wal file increase Thread-Topic: Wal file increase Thread-Index: AUF5anI2YaHEP911xq6wSXkemzP+eWxjMTNisoU2fLU= X-MS-Exchange-MessageSentRepresentingType: 1 Date: Mon, 15 Dec 2025 07:25:58 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: ar-SA X-Mentions: laurenz.albe@cybertec.at X-MS-Has-Attach: X-MS-Exchange-Organization-SCL: -1 X-MS-TNEF-Correlator: X-MS-Exchange-Organization-RecordReviewCfmType: 0 x-ms-reactions: allow Content-Type: multipart/alternative; boundary="_000_AM4P193MB2941220558624561A6A5F6EBAEADAAM4P193MB2941EURP_" MIME-Version: 1.0 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --_000_AM4P193MB2941220558624561A6A5F6EBAEADAAM4P193MB2941EURP_ Content-Type: text/plain; charset="windows-1256" Content-Transfer-Encoding: quoted-printable Dear @Laurenz Albe, Thanks for your support We have physical replication connection with Postgr= es node standby and have another replication slot with logical replication = with another node and every day after run pg_basebackup we face huge number= of file created and size per every hour is 23GB and in normal size is 0.8 = GB and in logical replication we see in logs it=92s in same checkpoint but = baseline change and we run pg_basebackup with -X fetch -C fast. Thanks ________________________________ =E3=E4: Laurenz Albe =FE=FE=CA=E3 =C7=E1=C5=D1=D3=C7=E1: Monday, December 15, 2025 8:31:05 AM =C5=E1=EC: kasem adel ; pgsql-admin =FE=FE=C7=E1=E3=E6=D6=E6=DA: Re: Wal file increase On Sun, 2025-12-14 at 17:30 +0200, kasem adel wrote: > Appreciate your usual support that we facing an issue when take pg_baseba= ckup for 4 TB > database in standby server and when backup finished we face huge number o= f wal file > with huge size generated for 6 hours the cause replication interruption. If you want help with that, you will have to give us enough information to = explain what happened. - What exactly is a "replication interruption", and how do you diagnose it? - Are you using streaming replication or logical replication? - If it is streaming replication, are you using a replication slot? - It is expected that if you suspend replication and have a replication slo= t, WAL will pile up on the primary. But what is the connection with pg_basebackup? Yours, Laurenz Albe --_000_AM4P193MB2941220558624561A6A5F6EBAEADAAM4P193MB2941EURP_ Content-Type: text/html; charset="windows-1256" Content-Transfer-Encoding: quoted-printable
Thanks for your support We have physical replication connection with Postgr= es node standby and have another replication slot with logical replication = with another node and every day after run pg_basebackup we face huge number= of file created and size per every hour is 23GB and in normal size is 0.8 GB and in logical replication we se= e in logs it=92s in same checkpoint but baseline change and we run pg_baseb= ackup with -X fetch -C fast.
Thanks
=E3=E4: Laurenz Albe <la= urenz.albe@cybertec.at>
=FE=FE=CA=E3 =C7=E1=C5=D1=D3=C7=E1: Monday, December 15, 2025 8:31:0= 5 AM
=C5=E1=EC: kasem adel <kasemadel8@gmail.com>; pgsql-admin <= pgsql-admin@postgresql.org>
=FE=FE=C7=E1=E3=E6=D6=E6=DA: Re: Wal file increase
 
On Sun, 2025-12-14 at 17:30 +0200, kasem adel wrot= e:
> Appreciate your usual support that we facing an issue when take pg_bas= ebackup for 4 TB
> database in standby server and when backup finished we face huge numbe= r of wal file
> with huge size generated for 6 hours the cause replication interruptio= n.

If you want help with that, you will have to give us enough information to = explain what
happened.

- What exactly is a "replication interruption", and how do you di= agnose it?

- Are you using streaming replication or logical replication?

- If it is streaming replication, are you using a replication slot?

- It is expected that if you suspend replication and have a replication slo= t, WAL will
  pile up on the primary.  But what is the connection with pg_bas= ebackup?

Yours,
Laurenz Albe
--_000_AM4P193MB2941220558624561A6A5F6EBAEADAAM4P193MB2941EURP_--