From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "Curtis Faith" <curtis(at)galtair(dot)com> |
Cc: | "Pgsql-Hackers" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Potential Large Performance Gain in WAL synching |
Date: | 2002-10-05 04:07:15 |
Message-ID: | 760.1033790835@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
"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?
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2002-10-05 04:17:00 | Re: Potential Large Performance Gain in WAL synching |
Previous Message | Bruce Momjian | 2002-10-05 03:53:37 | Re: Threaded Sorting |