Re: Potential Large Performance Gain in WAL synching - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Potential Large Performance Gain in WAL synching
Date
Msg-id 760.1033790835@sss.pgh.pa.us
Whole thread Raw
In response to Re: Potential Large Performance Gain in WAL synching  ("Curtis Faith" <curtis@galtair.com>)
Responses Re: Potential Large Performance Gain in WAL synching  (Bruce Momjian <pgman@candle.pha.pa.us>)
Proposed LogWriter Scheme, WAS: Potential Large Performance Gain in WAL synching  ("Curtis Faith" <curtis@galtair.com>)
List pgsql-hackers
"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?

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

As I commented before, I think we could do with an extra process to
issue WAL writes in places where they're not in the critical path for
a foreground process.  But that seems to be orthogonal from this issue.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Threaded Sorting
Next
From: Bruce Momjian
Date:
Subject: Re: Potential Large Performance Gain in WAL synching