From: | Martijn van Oosterhout <kleptog(at)svana(dot)org> |
---|---|
To: | ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp> |
Cc: | Takayuki Tsunakawa <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Load distributed checkpoint |
Date: | 2006-12-21 10:26:41 |
Message-ID: | 20061221102641.GB14992@svana.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
On Thu, Dec 21, 2006 at 06:46:36PM +0900, ITAGAKI Takahiro wrote:
> > Oh, really, what an evil fsync is! Yes, I sometimes saw a backend
> > waiting for lseek() to complete when it committed. But why does the
> > backend which is syncing WAL/pg_control have to wait for syncing the
> > data file? They are, not to mention, different files, and WAL and
> > data files are stored on separate disks.
>
> Backends call lseek() in planning, so they have to wait fsync() to
> the table that they will access. Even if all of data in the file is in
> the cache, lseek() conflict with fsync(). You can see a lot of backends
> are waiting in planning phase in checkpoints, not executing phase.
Hmm, there are other ways to sync parts of a file. For example doing an
mmap()/msync()/munmap() cycle to start an asyncronous flush. But given
what you're saying that might suffer from the same problem.
Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.
From | Date | Subject | |
---|---|---|---|
Next Message | Takayuki Tsunakawa | 2006-12-21 10:29:13 | Re: Load distributed checkpoint |
Previous Message | ITAGAKI Takahiro | 2006-12-21 09:46:36 | Re: Load distributed checkpoint |
From | Date | Subject | |
---|---|---|---|
Next Message | Takayuki Tsunakawa | 2006-12-21 10:29:13 | Re: Load distributed checkpoint |
Previous Message | Mark Morgan Lloyd | 2006-12-21 09:47:09 | Re: AGAIN - problem with BCC55 and libpq 8.2 |