On Fri, Jul 27, 2012 at 9:57 AM, Chris Angelico <rosuav@xxxxxxxxx> wrote: > On Fri, Jul 27, 2012 at 9:53 AM, Bruce Momjian <bruce@xxxxxxxxxx> wrote: >> You might want to look at the hackers list thread I started about the >> same topic a week before your post: >> >> http://archives.postgresql.org/pgsql-hackers/2012-07/msg00416.php >> >> Basically, you can only use mtime/size if you are replaying WAL. > > I'll check that out in a bit; but hot standby includes replaying WAL, > right? That's what we're doing - full live replication with > possibility to "pg_ctl promote" a slave straight up to master. Hi, thanks for that link. Just got a chance to read through the thread. In this post[1] the script executes "checkpoint" before "pg_start_backup" - is that important? According to the docs[2]: "There is an optional second parameter of type boolean. If true, it specifies executing pg_start_backup as quickly as possible. This forces an immediate checkpoint which will cause a spike in I/O operations, slowing any concurrently executing queries." Is "checkpoint; select pg_start_backup('foo');" the same as "select pg_start_backup('foo',true);"? And what are the consequences of not calling for a checkpoint that way? My understanding of the docs is that the pg_start_backup call will hang until a checkpoint happens organically, ie delaying the backup rather than other clients, but I'm not really sure and haven't a sample database big or busy enough to test this on. Other than that, I think our current setup is fine. I have a script that, every time a computer attempts to join the cluster, redoes the "start backup, rsync, stop backup" sequence. I'm depending on (and assuming) the correct transfer of the last bit of log via the replication link, as soon as the new slave starts up - presumably this'll all be provided from wal_keep_segments. Again, thanks for the pointer! A good read. ChrisA [1] http://archives.postgresql.org/pgsql-hackers/2012-07/msg00417.php [2] http://www.postgresql.org/docs/9.1/static/functions-admin.html -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
