Simon Riggs wrote: > > If it is a bug then I'd vote for just making it do an immediate > > checkpoint --- that might cause big I/O load but it's hardly likely to > > be worse than what will happen when you start taking the subsequent > > filesystem backup. > > It was a clear intention for it to *not* cause a spike if we could avoid > it. The idea was if you wanted it to happen quickly then you could do a > checkpoint command first... oh well. > > People might want to I/O limit the backup also, which they can do > without needing to let us know. > > I'm happy to put an option in for this, so we have another function: > pg_start_backup(label text, immediate_chkpt boolean). I'll not be > rushing to do this though given my current TODO.
I agree with Tom; either we make the pg_start_backup() checkpoint immediate or leave the behavior unchanged. Personally I think immediate makes more sense because issuing pg_start_backup() seems like it should behave like a manual CHECKPOINT command. -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-general mailing list (pgsql-general@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
