Re: hanging for 30sec when checkpointing

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>
Cc: "Goulet, Dick" <DGoulet(at)vicr(dot)com>, pgsql-admin(at)postgresql(dot)org
Subject: Re: hanging for 30sec when checkpointing
Date: 2004-02-10 16:41:33
Message-ID: 15924.1076431293@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-admin

"scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> writes:
>> Unfortunately not --- at checkpoint time, the constraint goes the other
>> way. We have to be sure all the data file updates are down to disk
>> before we write a checkpoint record to the WAL log. So you can still
>> get screwed if the data-file drive lies about write completion.

> Hmmm. OK. Would the transaction size be an issue here? I.e. would small
> transactions likely be safer against corruption than large transactions?

Transaction size would make no difference AFAICS. Reducing the interval
between checkpoints might make things safer in such a case.

> I ask because most of the testing I did was with pgbench running 100+
> simos (on a -s 100 pgbench database) and as long as the WAL drive was
> fsyncing correctly, the database survived.

Did you try pulling the plug immediately after a CHECKPOINT command
completes? You could test by manually issuing a CHECKPOINT while
pgbench runs, and yanking power as soon as the prompt comes back.

regards, tom lane

In response to

Responses

Browse pgsql-admin by date

  From Date Subject
Next Message scott.marlowe 2004-02-10 16:42:34 Re: Upgrading from 7.2 to 7.4.1 on Redhat 7
Previous Message Rajesh Kumar Mallah 2004-02-10 16:37:15 co existance of tsearch V1 and V2 in same database.