From: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
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:12:40 |
Message-ID: | Pine.LNX.4.33.0402100910400.28531-100000@css120.ihs.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin |
On Mon, 9 Feb 2004, Tom Lane wrote:
> "scott.marlowe" <scott(dot)marlowe(at)ihs(dot)com> writes:
> > That said we have a really HUGE (~200 drive) IDE storage array my web /
> > app server sits on top of. No clue if that thing will reliably work under
> > a database, and I'm in no hurry to find out.
>
> > But since the fsync on WAL is all that seems important, I could always
> > initlocation a big chunk of it and keep the WAL local and I should be ok.
>
> 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?
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.
From | Date | Subject | |
---|---|---|---|
Next Message | Palle Girgensohn | 2004-02-10 16:24:08 | Re: reduce downtime when upgrading 7.3 -> 7.4 |
Previous Message | scott.marlowe | 2004-02-10 16:08:28 | Re: hanging for 30sec when checkpointing |