On Tue, 2004-04-27 at 18:10, Peter Eisentraut wrote: > Simon Riggs wrote: > > New utility aimed at being located in src/bin/pg_arch > > Why isn't the archiver process integrated into the server? >
Number of reasons.... Overall, I initially favoured the archiver as another special backend, like checkpoint. That is exactly the same architecture as Oracle uses, so is a good starting place for thought. We discussed the design in detail on the list and the suggestion was made to implement PITR using an API to send notification to an archiver. In Oracle7, it was considered OK to just dump the files in some directory and call them archived. Later, most DBMSs have gone to some trouble to integrate with generic or at least market leading backup and recovery (BAR) software products. Informix and DB2 provide open interfaces to BARs; Oracle does not, but then it figures it already (had) market share, so we'll just do it our way. The XLogArchive design allows ANY external archiver to work with PostgreSQL. The pg_arch program supplied is really to show how that might be implemented. This leaves the door open for any BAR product to interface through to PostgreSQL, whether this be your favourite open source BAR or the leading proprietary vendors. Wide adoption is an important design feature and the design presented offers this. The other reason is to do with how and when archival takes place. An asynchronous communication mechanism is required between PostgreSQL and the archiver, to allow for such situations as tape mounts or simple failure of the archiver. The method chosen for implementing this asynchronous comms mechanism lends itself to being an external API - there were other designs but these were limited to internal use only. You ask a reasonable question however. If pg_autovacuum exists, why should pg_autoarch not work also? My own thinking about external connectivity may have overshadowed my thinking there. It would not require too much additional work to add another GUC which gives the name of the external archiver to confirm execution of, or start/restart if it fails. At this point, such a feature is a nice to have in comparison with the goal of being able to recover to a PIT, so I will defer this issue to Phase 3.... Best regards, Simon Riggs ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
