From: | Doug Fields <dfields-pg-general(at)pexicom(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org, Glenn Stone <gstone(at)pogolinux(dot)com> |
Subject: | Re: WAL recycling, Linux 2.4.18 |
Date: | 2002-07-08 20:24:15 |
Message-ID: | 5.1.0.14.2.20020708162207.01f5edb0@pop.pexicom.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
At 04:12 PM 7/8/2002, Tom Lane wrote:
>This is beginning to look like a kernel problem.
Sigh. The hardest ones to fix. It's very nice however that the fsync=off
fixes the immediate problem, inasmuch as I can run with that for the moment
until such a time as we figure out the "real" problem.
>That should be FSYNC not FSYNCA, I believe.
OK I'll try that.
> > Of note, in the fdatasync() man page: Currently (Linux 2.2)
> > fdatasync is equivalent to fsync.
>
>Are you really using a 2.2 kernel? I thought that that point had been
>fixed in 2.4 kernels. (I see the comment is still there in the man page
>on my RH7.2 box, though.)
No, I'm using 2.4.18 on Debian/Woody, but as you say, the man page still
refers to 2.2.
>Now that we've eliminated MoveOfflineLogs as the time-consuming part of
>checkpoint, would you make the same check for mdsync()? That's the
>routine that actually issues the sync() calls. Again, it would be
>useful to know how long it takes, and whether the other backends appear
>to be blocked at the times mdsync() is entered and exited.
Will do.
Thanks,
Doug
From | Date | Subject | |
---|---|---|---|
Next Message | Sam Liddicott | 2002-07-08 20:28:33 | Re: 7.2.1 optimises very badly against 7.2 |
Previous Message | Tom Lane | 2002-07-08 20:12:09 | Re: WAL recycling, Linux 2.4.18 |