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