On Tue, Oct 31, 2017 at 9:53 AM, Rhhh Lin <ruanlinehan@xxxxxxxxxxx> wrote: > I would actually be an advocate for using a proper archive_command in order > to facilitate a proper (Per the documentation) PITR and backup strategy. You should avoid using your own fancy archive command. There are things that WAL-E for this purpose, and even if you do make sure that the segment data is flushed to disk before sending back 0 as exit code to the client. > However, a colleague had suggested such a creative approach (Possibly, less > administrative overhead, ease of maintenance? I'm not sure) and I struggled > to find any evidence online in blogs/white-papers/documentation that this > was a feasible approach. That said, I couldn't find any info rejecting it as > a method either, which led me to post here. Essentially, this was a > difference of opinion on approach, and I was looking to gather information > in order to make an informed opposing argument. Backup methods should not be fancy, just reliable. > My only thought now would be how could I decipher, within the sequence chain > of WAL files, up to which file has the "archival" progressed to. i.e. which > files are not susceptible to being called upon again for > restartpoints/checkpoints. That is, where is my absolute point (or file) of > archival using something along the lines of 'pg_current_xlog_location'. There is the system view called pg_stat_archiver for that. If you are using something like pg_receivexlog, pg_stat_replication is the way to go to monitor the archiving progress. -- Michael -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
