On Tue, 2008-09-30 at 12:58 +0400, Ivan Zolotukhin wrote:
> Just a few points on pg_start_backup() from user point of view. I
> personally would prefer to have some control over the process, e.g. it
> would be nice to have proposed pg_start_backup(label text,
> immediate_chkpt boolean).
I've ad
On Mon, Sep 29, 2008 at 2:12 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Mon, 2008-09-29 at 13:39 +0400, Ivan Zolotukhin wrote:
>
>> This is all not about checkpoints. As I've mentioned in the first
>> message, even right after manual run of CHECKPOINT command in psql
>> pg_start_backup() tak
On Mon, 29 Sep 2008 19:06:46 -0400 (EDT)
Bruce Momjian <[EMAIL PROTECTED]> wrote:
> 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
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 *
On Mon, 29 Sep 2008, Simon Riggs wrote:
I'm surprised that checkpoint smoothing moves slowly even when it has so
little to do. ISTM checkpoint completion target should set its write
rate according to the thought that if shared_buffers were all dirty it
would write them out in checkpoint_timeou
On Mon, 2008-09-29 at 08:35 -0400, Tom Lane wrote:
> Simon Riggs <[EMAIL PROTECTED]> writes:
> > I'm surprised that checkpoint smoothing moves slowly even when it has so
> > little to do.
>
> AFAIK that's operating as designed. The point being that we shouldn't
> create any more I/O load than we
Simon Riggs <[EMAIL PROTECTED]> writes:
> I'm surprised that checkpoint smoothing moves slowly even when it has so
> little to do.
AFAIK that's operating as designed. The point being that we shouldn't
create any more I/O load than we absolutely have to.
It's not clear to me that it's a bug for p
On Mon, 2008-09-29 at 13:39 +0400, Ivan Zolotukhin wrote:
> This is all not about checkpoints. As I've mentioned in the first
> message, even right after manual run of CHECKPOINT command in psql
> pg_start_backup() takes same time (~10 minutes).
As explained, there's not very much going on apart
Guys,
This is all not about checkpoints. As I've mentioned in the first
message, even right after manual run of CHECKPOINT command in psql
pg_start_backup() takes same time (~10 minutes).
Regards,
Ivan
On Sun, Sep 28, 2008 at 8:18 PM, Simon Riggs <[EMAIL PROTECTED]> wrote:
>
> On Sun, 2008-09-2
On Sun, 2008-09-28 at 08:35 -0700, Joshua D. Drake wrote:
> Ivan Zolotukhin wrote:
> > Hello,
> >
> > Nothing bad both in system and postgres logs :( No serious activity
> > during backup. I've had to change statement_timeout for backup user to
> > make it work. But I cannot reproduce this case u
Ivan Zolotukhin wrote:
Hello,
Nothing bad both in system and postgres logs :( No serious activity
during backup. I've had to change statement_timeout for backup user to
make it work. But I cannot reproduce this case unfortunately.
This is actually not uncommon and PostgreSQL shows exactly noth
Hello,
Nothing bad both in system and postgres logs :( No serious activity
during backup. I've had to change statement_timeout for backup user to
make it work. But I cannot reproduce this case unfortunately.
Regards,
Ivan
On Tue, Sep 23, 2008 at 6:18 AM, Bruce Momjian <[EMAIL PROTECTED]> wrote:
Ivan Zolotukhin wrote:
> Hello,
>
> What is the reason for
>
> select pg_start_backup('label');
>
> taking 10 minutes on not so loaded system even right after manual checkpoint?
No idea; something is seriously wrong if that is happening. Do the
database server logs or kernel logs show anythin
Hello,
What is the reason for
select pg_start_backup('label');
taking 10 minutes on not so loaded system even right after manual checkpoint?
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-gene
14 matches
Mail list logo
