Re: WAL recycling, Linux 2.4.18

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Doug Fields <dfields-pg-general(at)pexicom(dot)com>
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:12:09
Message-ID: 26552.1026159129@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Doug Fields <dfields-pg-general(at)pexicom(dot)com> writes:
> FSYNC=OFF results:
> What a difference. My checkpoints are just as long - they still take quite
> a bit of time to process and do a lot of "blocks out" on the vmstat - but
> queries now longer block waiting for them to finish.

This is beginning to look like a kernel problem.

> FSYNCA - gives runtime error: FATAL 1: invalid value for option
> 'WAL_SYNC_METHOD': 'FSYNCA'
> and refuses to start

That should be FSYNC not FSYNCA, I believe.

> 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.)

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.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Doug Fields 2002-07-08 20:24:15 Re: WAL recycling, Linux 2.4.18
Previous Message Doug Fields 2002-07-08 20:00:48 Re: WAL recycling, Linux 2.4.18