Re: Command to prune archive at restartpoints

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>  The purpose of making this a standalone executable is
>>> so that people who have, for example, multiple standbys, can customize
>>> the logic without having to hack the backend.  Pushing this into the
>>> backend would defeat that goal; plus, it wouldn't be usable at all for
>>> people who aren't running Hot Standby.
>
> We're not going to make them cut/paste anything from the docs. We're
> going to provide a production-ready executable they can just use,
> which should be installed (presumably, already with the correct
> permissions) by their packaging system if they install
> postgresql-contrib or the equivalent.

I still run against people not wanting to trust contrib. I still read
here from time to time that contrib's chapter is maintaining working
examples of extensibility, not maintaining production ready add-ons.

Other than that, you proposed something flexible and easy to customize,
and you end up with an executable binary that will only offer one
behavior (unlink), the only option is where to stop (%r).

The backend function I'm proposing uses the same option, but is easier
to call from a script, should you need to customize. You don't even have
to run the script locally or remember where is the XLOG directory of
that instance. You could operate over a JDBC connection, e.g.

I now realize that my proposal ain't helping if Streaming Replication is
filling the standby's pg_xlog and hot_standby = off. I don't remember
that SR rebuilds pg_xlog on the standby though, does it?

The proposed script will only cleanup XLOGDIR in fact, so if you use a
common archive elsewhere then you still need some external command not
provided by the project. So we still need the script example in the
docs.

I think that the pg_archivecleanup binary is a good solution, all the
more if not shipped in contrib, but that the SQL callable function is
better.

Regards,
--
dim