Robert Haas <robertmh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
