Skip site navigation (1) Skip section navigation (2)

Re: Load distributed checkpoint

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 (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-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.

In response to

pgsql-hackers by date

Next:From: Takayuki TsunakawaDate: 2006-12-21 10:29:13
Subject: Re: Load distributed checkpoint
Previous:From: ITAGAKI TakahiroDate: 2006-12-21 09:46:36
Subject: Re: Load distributed checkpoint

pgsql-patches by date

Next:From: Takayuki TsunakawaDate: 2006-12-21 10:29:13
Subject: Re: Load distributed checkpoint
Previous:From: Mark Morgan LloydDate: 2006-12-21 09:47:09
Subject: Re: AGAIN - problem with BCC55 and libpq 8.2

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group