Re: Potential Large Performance Gain in WAL synching

Tom Lane wrote:
> "Curtis Faith" <curtis@galtair.com> writes:
> > After some research I still hold that fsync blocks, at least on
> > FreeBSD. Am I missing something?
> 
> > Here's the evidence:
> >         [ much snipped ]
> >         vp = (struct vnode *)fp->f_data;
> >         vn_lock(vp, LK_EXCLUSIVE | LK_RETRY, p);
> 
> Hm, I take it a "vnode" is what's usually called an inode, ie the unique
> identification data for a specific disk file?

Yes, Virtual Inode.  I think it is virtual because it is used for NFS,
where the handle really isn't an inode.

> This is kind of ugly in general terms but I'm not sure that it really
> hurts Postgres.  In our present scheme, the only files we ever fsync()
> are WAL log files, not data files.  And in normal operation there is
> only one WAL writer at a time, and *no* WAL readers.  So an exclusive
> kernel-level lock on a WAL file while we fsync really shouldn't create
> any problem for us.  (Unless this indirectly blocks other operations
> that I'm missing?)

I think the small issue is:
proc1        proc2writefsync        write        fync

Proc2 has to wait for the fsync, but the write is so short compared to
the fsync, I don't see an issue.  Now, if someone would come up with
code that did only one fsync for the above case, that would be a big
win.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073