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 1pxT62-0005qF-Om for pgsql-novice@arkaria.postgresql.org; Fri, 12 May 2023 13:46:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pxT61-0004gs-FS for pgsql-novice@arkaria.postgresql.org; Fri, 12 May 2023 13:46:09 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pxT61-0004gj-7K for pgsql-novice@lists.postgresql.org; Fri, 12 May 2023 13:46:09 +0000 Received: from mail-pj1-x102e.google.com ([2607:f8b0:4864:20::102e]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1pxT5y-001wFl-9S for pgsql-novice@postgresql.org; Fri, 12 May 2023 13:46:08 +0000 Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-24df6bbf765so8681158a91.0 for ; Fri, 12 May 2023 06:46:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683899165; x=1686491165; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=ZP/U1L73sQtjIe1PKkFyxvNNsglZzlxArM7GQijaH2w=; b=joXxXeyw0XgpVL/7XRgYwPTw5Q4qjbf91gmVmIXrhNCMyGwxDKbgMreEy4UPLPa8ix H8O71ElWBsCzdpTu4A5Mk7/gd4KIz0a2U0syc8sEOZOlVt1makr81xpDUYvKcvo1yUYF Rr6srTHb8HA8dBag5rMyxZJrYGDeO2T8CwU54/dXCQ9FJK5R/NoOqG7NsebvX69lMk2n I07Nb00KtkIqfaBSbvtf3bPcjfjdIJaSuUb91obFVdOgad3K6gZwiDywYeRurlLrYQCx kuA7dkL+g6QAbp6yU3DNiJ7n2g/BGCUTLlSf2Qu/lNkULT2C7HL8XJjTk0oFaMGC8LxV ZaWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683899165; x=1686491165; h=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=ZP/U1L73sQtjIe1PKkFyxvNNsglZzlxArM7GQijaH2w=; b=Oti3WgTId9KTwNDY4k1ck0A8oLq2IXbFFuaiwncxUql+35jy3kPl0RZD5TcwEqv2he SQLA7k7hIQAHymFymzmT1HLAOzWYOcqnbcl0FT9M1BvVKSVGq1wq0ZZuaTspkvqIbF2f wAcHxXqzfzr/iSIJEfzsYWoSPeEoztJQ2yqr0PeFUCeu+0s29qEMBarrx6W47LVk7n4h VMKQtUZgKbsgqao0zcDSHZ1L7VClPlFAeduftCOes7vLaFO46sj5d7DKyActtzHWfj7d iKOXd6avzfo0pzRnVazv4CHZ3f3+AoU4+Jr5/vKaLrF/VIj8aN4zD+bJ0eWrJszIy6Nd G5zg== X-Gm-Message-State: AC+VfDwO0XfmcXMOTRzwy1Jf9w5VfaD+2x7VSPqKWnC25n8giWi2rh54 9GAM23JvJmYh7lotjpuWf6Sm1HkOiYqvJhHUdaU= X-Google-Smtp-Source: ACHHUZ5xoM9LJN+yQyJgacmqd5VJtncP8q2GlShK78TKZSSHHJoMFYtn5e+NAtSpnjwMQy6DrgdTA2kw/BsE7tDB6+8= X-Received: by 2002:a17:90a:a590:b0:247:eae:1787 with SMTP id b16-20020a17090aa59000b002470eae1787mr25160428pjq.36.1683899165275; Fri, 12 May 2023 06:46:05 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Yang Steve Date: Fri, 12 May 2023 23:45:53 +1000 Message-ID: Subject: Re: recovery.conf and archive_cleanup_command To: Laurenz Albe Cc: Rita , pgsql-novice@postgresql.org Content-Type: multipart/alternative; boundary="000000000000957b7e05fb7f531d" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000957b7e05fb7f531d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I am using PostgreSQL Version 15 now, however, archive_cleanup_command only triggered on standby box, not on primary. Is that expected as designing? Laurenz Albe =E4=BA=8E2022=E5=B9=B410=E6=9C=8810= =E6=97=A5=E5=91=A8=E4=B8=80 04:33=E5=86=99=E9=81=93=EF=BC=9A > On Sat, 2022-10-08 at 08:51 -0400, Rita wrote: > > I have primary and standby replication setup. > > > > On my primary the archive directory is rather large (30GB) and growing. > On my standby I have recovery.conf which has > > archive_cleanup_command =3D 'pg_archivecleanup -d > /var/lib/pgsql/11/data/archive %r' > > > > I was under the impression this line would remove data from my primary > AND standby. Is that not the case? > > That depends on your PostgreSQL version, for instance. > > Also, it depends on whether the standby server is running and actually > recovering. > Finally, it depends on whether the standby can execute the command > successfully or not. > > Did you look at the standby's logs? > > Yours, > Laurenz Albe > -- > Cybertec | https://www.cybertec-postgresql.com > > > --000000000000957b7e05fb7f531d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I am using PostgreSQL Version 15 now, however,=C2=A0archive_cleanup_command only triggered on stan= dby box, not on primary. Is that expected as designing?=C2=A0
<= br>
Laurenz= Albe <laurenz.albe@cybertec= .at> =E4=BA=8E2022=E5=B9=B410=E6=9C=8810=E6=97=A5=E5=91=A8=E4=B8=80 = 04:33=E5=86=99=E9=81=93=EF=BC=9A
On Sat, 2022-10-08 at 08:51 -0400, Rita wrote:
> I have primary and standby replication setup.
>
> On my primary the archive directory is rather large (30GB) and growing= . On my standby I have recovery.conf which has=C2=A0
> archive_cleanup_command =3D 'pg_archivecleanup -d /var/lib/pgsql/1= 1/data/archive %r'
>
> I was under the impression this line would remove data from my primary= AND standby. Is that not the case?

That depends on your PostgreSQL version, for instance.

Also, it depends on whether the standby server is running and actually reco= vering.
Finally, it depends on whether the standby can execute the command successf= ully or not.

Did you look at the standby's logs?

Yours,
Laurenz Albe
--
Cybertec | https://www.cybertec-postgresql.com


--000000000000957b7e05fb7f531d--