Re: Potential Large Performance Gain in WAL synching

Tom Lane wrote:
> "Curtis Faith" <curtis(at)galtair(dot)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 proc2
write
fsync 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(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073