From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ivan Zolotukhin <ivan(dot)zolotukhin(at)gmail(dot)com>, "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, PostgreSQL General <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: pg_start_backup() takes too long |
Date: | 2008-09-29 23:06:46 |
Message-ID: | 200809292306.m8TN6kX20231@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
From | Date | Subject | |
---|---|---|---|
Next Message | Joshua Drake | 2008-09-29 23:26:28 | Re: pg_start_backup() takes too long |
Previous Message | Greg Smith | 2008-09-29 22:14:53 | Re: database question |