On Thu, 2007-10-11 at 16:37 +0200, Thomas Karcher wrote: > Hi Tom, > > > > My idea is now: When doing a consistent PITR backup, extend the > > > documented steps between 4 (pg_stop_backup()) and 5 (wait for archived > > > WAL file) with a busy wait on pg_xlog/archive_status/*.ready files - as > > > soon as no .ready files are there anymore, the archiver has done its > > > work, and I can safely backup the archived WAL files in order to have a > > > really consistent backup. > > If the database is busy, you might never see an instant where there are > > no .ready files. Certainly it's possible that this approach will > > archive many more segments than you need. > > I see - but the risk for never seeing an instant without .ready files is > relatively slow, I hope. And compared to the risk of not having a > consistent backup, I could live with having backed up more WAL files > than I actually would have needed. There will be gaps, otherwise the archiver will never catch up over time, but its hard to say when those might be. > > > Is that right? Or is there an easier way to do it? > > I believe the intended way to do this is to look at pg_stop_backup's > > return value to determine the last segment you need to archive. > > Thank you - I saw that, but I didn't have a clue about how to determine > the WAL filename in which this segment is to be found ... Look at pg_stop_backup() in the docs. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
