Robert Haas <robertmhaas@gmail.com> writes:
> I'm a bit perplexed here. The archive cleanup has to run on the
> standby, not the master, right? Whereas pg_switch_xlog() can only run
> on the master.
I used it just to show a possible use case, easy to grasp. Sorry if
that's confusing instead.
> 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.
In the simple cases, what you want to be able to easily choose is just
the first XLOG file you're NOT cleaning. And this is the only argument
you give the function.
So you can either use the backend function as your internal command for
archive cleanup, or use a script that choose where to stop cleaning then
call it with that as an argument (it's SQL callable).
What it does is unlink the file. If that behavior doesn't suit you, it's
still possible to use an external command and tune some already proposed
scripts. I just don't see how an external binary has more to offer than
a backend function here. It's more code to maintain, it's harder to
setup for people, and if it does not suit you, you still have to make
you own script but you can not use what we ship easily (you have to get
the sources and code in C for that).
What I'm after is being able to tell people to just setup a GUC to a
given value, not to copy/paste a (perl or bash) script from the docs,
make it executable under their system, then test it and run it in
production. We can do better than that, and it's not even hard.
Regards,
--
dim
