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 1mJZWu-0003ls-7R for pgsql-admin@arkaria.postgresql.org; Fri, 27 Aug 2021 10:56:12 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mJZWt-0007Tv-6s for pgsql-admin@arkaria.postgresql.org; Fri, 27 Aug 2021 10:56:11 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mJZWs-0007Ob-K3 for pgsql-admin@lists.postgresql.org; Fri, 27 Aug 2021 10:56:10 +0000 Received: from sonic311-23.consmr.mail.ne1.yahoo.com ([66.163.188.204]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1mJZWq-0008QE-Tr for pgsql-admin@lists.postgresql.org; Fri, 27 Aug 2021 10:56:10 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1630061765; bh=vLCCeLJ0hweuyoQ6UDvYBTzava7Vm03XQSBWbG/qM0A=; h=Date:From:Reply-To:To:In-Reply-To:References:Subject:From:Subject:Reply-To; b=AN/D+Fogtli4kAjMUy7nT+NUuBKO1ciJKKU4KLknpAVXrnMMHQSsWgRL7DHZwR2yEjJysoeBd2B5IOUjz8mdvLmapO7Wsx99xTirx/KzW9TvFtEqkisHT473l5KI07lCtyTMh3f6pVIq6NdgWq8Z1ZuVql4m3VMuTRQFvFASQOgkmQ3mqMDk8bF61mWNR18F4pb3LGVMz9ldWPptvpk0pj7ZekZJthl4S4+arVvJ6Q042NIvF5HURyFVjkHWmYpSMorbYz/A8GJCWOlhXh52n24X1J+BEX3mXzRsnTjtC56ljs/ltfwiIt6pW+MvUQneGTHAJAvoKG0D7okRMUK+5g== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1630061765; bh=/IyykvbQ/HhdS/yxgdS81mxN/FYVy3OkSmZT/c6CejJ=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=Wwf2NJ5kpS+47P/lZ8aDxDZy9LIUf0ugWpoz3O7n9RnzPrgV/3BhChYc1P0RhjHG6h5IaDJx3MIt52ayy0aNEyeRyfNYRbj7EBxPwI6YnANVKe/+UGsKJslBikosH/xn53fRUVaVzY9HZQgnNMyNAPBew0narUDkJvbFHd18fdgJFfjpTexYa2X8RdU4aeTKLcYbEtLgk2PUQUOzjrhis2AqW6poyaTTwUOXv3OJN8kq0cKurGX+KGamujoTUBR/B1zXJHlcGON5uXR0gEgc3YydAplKTBUOsttLLHuCgvt5+kMCEDmOswNGjEX4dt8ul52WKw/6ozrhvQ3mq6AxqA== X-YMail-OSG: nVhr5REVM1mkUUT_WLMUjO5sbz4KH5oNKbAdH9cxcoGXx6rpYn0lvB4WRa5zsP_ 3lEiqFT9b9xLzX72IViQitDvpKIW3UyAUORRi4aEpLqpsmEK8ge1XcedWJ_FaT7poLXkCU9uuaI9 n_dXeIaWzGjfGAt2Vs754MYQulek7dMY2_PRqI6sxJONvZejrIFlTPZ5kISGhKwhg1.NcKpjg3JT go.g7rxZJOj5i_OkgnGnk.Bw03aBCrGjFsk6e4wr_5YCz68O8uBcdMorRC0a3CQI11kGQA5HqSn1 wyTavNjSqmPJCiw8_ebc5b60X5qRmzgb1LQZvdynwwCnQa3lmgthnc8Idng8VDsrNsOJAcC7GzYy f.7ps5GO7WVQe4NGzMnqnzynOvOsWUkNOGkxCmRo1aoJgQ1dFfBW_EF_E7jAK.m6bCKXR1kHN65t usE5UpVK9ZsP8XCmEzyC0X9px4I6uK.7w7gyRn9vDM7R6KLkTHxAvfBd1vMA6LBefOv7blTxKVci b337RVq5lJ2Jz64cPAHuas3fKiBD_JPdFLixDrprMx3nBysa_zoS4E8SlAKHjNCE0wp3v.guuPd2 2BSCIL0H1craK_WgfOO9S7XqGhC48LHoD7Smu2d5UuSDvgnA3TGClPKhb9NmZgrRmBvXDuVWx8Q1 H.XCjZU7PXi.GmAe15cxuG.EwR8PiIxoFqgZLNaO6cIsGQK6UviyvxPHLzpzqw0wenrfVKm2SO.T m5l9KUbli2PMpm1q5Y__GM_pvc7hAOt0gOMZv_GXJJQtmMfAfJSi1N2SJ_yU6buyTkWt0U0Ht8OO J83n3rivByilZsCD0VY2V8vpf99VG3PUHU6onFJclgTOF.rrVSMh40O0KY3RYU2_VIY1TjJdv80T l8Y.dzgaQl3_cxGB.WCuYgnMm9GVUoYc7IjwP4zhxkujMQunC3WWZAVkLXzsbwWFl.XlKkegk7Sa oH2i_I8H6rpSI4SSgQckyJzk5gvMARZBg_IJjLsa_xgrHTp7a1YTetBbd3C.t2jmAZ38oqS5rbIq bEzDmXngkAGB1QWTBx0AljmIrKyhkmBkikR0IDDiHygthM3G8Q3tQKnxI61irXB6_MtbO14s4ITD E1oLlITaqracKgESuH6j61IBgVws4vjMluD0G1YaHwuVaWwfMniOXMMi0NZ0VUW0t2CEvP0iu2Zz 53_upxaTflNMZmTJ2fm34_gMAkVG5utwx5y8z4.cs2nkuzSvKbnJiUSG5CgbAb2p72fEzBP1IXl. c64pfBbHxuWiMan_PHgkf0zBoHmKqpPBiBSmtmdQV8qsquFeu8WGXN1AZWfWN0mIV6t5uS1HYgn8 BaZNchdaSyxJA2VFBGfOrNPl9OYghto5mP.q2O3cbPHtDc5Bi.dB0bRMbTw_QbnDH8yWQLQSeqJo AvJKZXUZzWptDWUtqRqgo3jD4fTb994fKw9blFSGWsjgBfCDnALB6ot_Bbzy3g6ALVESQtK9tmlf iwIToDvp9uEwDEUPaqp6RxjI8cXDMOQseVN8k9BJUwdPVprz44EfEosrkMvMTdW5.umxBIsS0kzQ VR9CPVBStdCy.ocrjtdPBjtbRu9sO5h8CYJAcKdymSRhsgZKBhaeFjEdhVsDyyI5LD7vyr3hUN7. 1mfrD0x9PRyqC1mDzJZDkSXo9HL_2zIrTfEE7DY28PZUesIl6RjRuyqeUX5jQEiYH6mNcZqohXUw .5XoTx7pr7EWr7Wqs7D50MJ_unNKL2QfiT5o_Rs1R3b96Qj85xyh.YNAfypGpBD5CiKtVBA8LxI7 eWM9Xm.kFgzJMjyUVd6h4QyLiPRZvWkZXg42N1STg8C62N6mo4rKwp5x8Hk4fnzzxorJee5cr6J_ ejp1wdDzPxz1QxBadxs_FyR4DIFeQ_n8NNuuRsi8S3SiXXob9fIG3mWxxCH2GEX9gIiGVmVcNip6 d7HeCMGt1dLrtrSWJDHPgffaAbZf7Sgati7NtFUeBEPUWHS9BzmvP.rEimYDof01CAhob4Cnkxkp flbt5feZf0XkKj21_uD4iEK4Ofd3s0zZQz_XKON7eHRjUTh2z.AoOLvAK0RUoI1pD5.2MOCVcwmn DFVsvv22xakadSWstbl4LqnCv26DBrkAcQvY0rvtkPFOqMMUPLYVhH3CGGX6t29yv0z3HODf4sAL zEd4jrURnyGW411NiYClYH6.QMjamJRCteij_o9EJ5_INFU_RWwm7a9AYX19IZOec7FMyyfuYQPq Uw7D_ea9jfoyyXLeV7CVWWEk.PWCX5II3CSCBOSRCopElAF.n5QwneAsY5jj_y9nhHBs9DJ2SwGb j4zNr70Td2NE4CHAQBAIcJBpsORUDzT_ISJt2qisRgNRCOQ-- X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic311.consmr.mail.ne1.yahoo.com with HTTP; Fri, 27 Aug 2021 10:56:05 +0000 Date: Fri, 27 Aug 2021 10:56:01 +0000 (UTC) From: Pepe TD Vo Reply-To: Pepe TD Vo To: Pgsql-admin , Laurenz Albe Message-ID: <1948635055.176990.1630061761986@mail.yahoo.com> In-Reply-To: <1e79ea171debe2b3ed9c297989f110cfccdf129b.camel@cybertec.at> References: <1415172523.18991.1630012160409.ref@mail.yahoo.com> <1415172523.18991.1630012160409@mail.yahoo.com> <1e79ea171debe2b3ed9c297989f110cfccdf129b.camel@cybertec.at> Subject: Re: slave stops replica MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_176989_846646761.1630061761985" X-Mailer: WebService/1.1.18924 YMailNorrin Content-Length: 4788 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk ------=_Part_176989_846646761.1630061761985 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Can we delete the old WALs?=C2=A0 May I know what=C2=A0 is the retention to= perform tuning on the server like Oracle to keep only 7 days and why=C2=A0= pg_archivecleanup doesn't work? Bach-Nga =20 On Friday, August 27, 2021, 03:29:54 AM EDT, Laurenz Albe wrote: =20 =20 On Thu, 2021-08-26 at 21:09 +0000, Pepe TD Vo wrote: > I had master slave replica and yesterday the slave server's device was fu= ll on /var > where the archive copy from master.=C2=A0 After trying to figure out why = the > pg_archivecleanup doesn't work, SA removed all wal files except the=C2=A0= current >=20 > I tried to create a test table on master and didn't see it pick up from s= lave. > I found out again /var is full.=C2=A0 If you have deleted WAL that has no yet been applied to the standby, replic= ation is broken and you have to build the standby from scratch. Yours, Laurenz Albe --=20 Cybertec | https://www.cybertec-postgresql.com =20 ------=_Part_176989_846646761.1630061761985 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Can we delete the old WALs?&nb= sp; May I know what  is the retention to perform tuning on the server = like Oracle to keep only 7 days and why pg_archivecleanup doesn't wor= k?

= Bach-Nga


<= /span>


=20
=20
On Friday, August 27, 2021, 03:29:54 AM EDT, Laurenz Al= be <laurenz.albe@cybertec.at> wrote:


On Thu, 2021-08-26 at 21:09 +0000, Pe= pe TD Vo wrote:

> I had master slave replica and yesterday the slave server's devi= ce was full on /var
> where the archive copy from mast= er.  After trying to figure out why the
> pg_arch= ivecleanup doesn't work, SA removed all wal files except the  current<= br clear=3D"none">>
> I tried to create a test tab= le on master and didn't see it pick up from slave.
> I= found out again /var is full. 


If you have deleted WAL that has no yet been applied to the standby, r= eplication
is broken and you have to build the standby fr= om scratch.

Yours,
L= aurenz Albe
--
Cybertec | https:= //www.cybertec-postgresql.com




------=_Part_176989_846646761.1630061761985--