Message-ID: <ba11cdeae97035e94894dd5eb56346f831abc8a6.camel@cybertec.at>
Subject: Re: recovery.conf and archive_cleanup_command
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: Yang Steve <steve25insydney.yang@gmail.com>
Cc: Rita <rmorgan466@gmail.com>, pgsql-novice@postgresql.org
Date: Fri, 12 May 2023 16:52:56 +0200
In-Reply-To: 
 <CAH4uYX5dweEnoUgi8Z4tLfuX7K3stY84N+Z=iq9sxsQB=pY2Kg@mail.gmail.com>
References: 
	<CAOF-KfhGM28vyE+HShrfnTNx8PYBeyTkiNGDA_xPF1DDS_PEHg@mail.gmail.com>
	 <a50f44d5dbb3bef00594c7539479b29ca464a0dc.camel@cybertec.at>
	 <CAH4uYX5dweEnoUgi8Z4tLfuX7K3stY84N+Z=iq9sxsQB=pY2Kg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/ba11cdeae97035e94894dd5eb56346f831abc8a6.camel%40cybertec.at>
Precedence: bulk

On Fri, 2023-05-12 at 23:45 +1000, Yang Steve wrote:
> Laurenz Albe <laurenz.albe@cybertec.at> =E4=BA=8E2022=E5=B9=B410=E6=9C=88=
10=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.
> > >=20
> > > On my primary the archive directory is rather large (30GB) and growin=
g. On my standby I have recovery.conf which has=C2=A0
> > > archive_cleanup_command =3D 'pg_archivecleanup -d /var/lib/pgsql/11/d=
ata/archive %r'
> > >=20
> > > I was under the impression this line would remove data from my primar=
y AND standby. Is that not the case?
> >=20
> > That depends on your PostgreSQL version, for instance.
> >=20
> > Also, it depends on whether the standby server is running and actually =
recovering.
> > Finally, it depends on whether the standby can execute the command succ=
essfully or not.
> >=20
> > Did you look at the standby's logs?
>
> I am using PostgreSQL Version 15 now, however, archive_cleanup_command on=
ly triggered on standby box, not on primary.
> Is that expected as designing?

Yes.  It is a recovery parameter, and they are only used if PostgreSQL is i=
n recovery.
The parameter makes no sense unless you are recovering.

Yours,
Laurenz Albe