Re: [PATCH] remove pg_archivecleanup and pg_standby

From: Justin Pryzby <pryzby(at)telsasoft(dot)com>
To: Michael Banck <michael(dot)banck(at)credativ(dot)de>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, Ian Lawrence Barwick <barwick(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] remove pg_archivecleanup and pg_standby
Date: 2020-11-02 18:26:21
Message-ID: 20201102182621.GH22691@telsasoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Oct 29, 2020 at 08:40:31PM +0100, Michael Banck wrote:
> Am Mittwoch, den 28.10.2020, 21:44 -0500 schrieb Justin Pryzby:
> > Forking this thread:
> > https://www.postgresql.org/message-id/fd93f1c5-7818-a02c-01e5-1075ac0d4def@iki.fi

> > I think these are old-fashioned since 9.6 (?), so remove them for v14.
>
> Why 9.6?

My work doesn't currently bring me in contact with replication, so I've had to
dig through release notes. I think streaming replication was new in 9.0, and
increasingly mature throughout 9.x. Maybe someone else will say a different
release was when streaming replication became the norm and wal shipping old.

> > I found it confusing when re-familiarizing myself with modern streaming
> > replication that there are extensions which only help do things the "old way".
>
> I guess not many will complain about pg_standby going away, but I am
> under the impression that pg_archivecleanup is still used a lot in PITR
> backup environments as a handy tool to expire WAL related to expired
> base backups. I certainly saw hand-assembled shell code fail with "too
> many files" and things when it tried to act on large amount of WAL.

I anticipate you're right, and I'll withdraw 0002.

--
Justin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jesse Zhang 2020-11-02 18:28:33 Re: upcoming API changes for LLVM 12
Previous Message Anastasia Lubennikova 2020-11-02 18:05:27 Re: WIP: BRIN multi-range indexes