[EMAIL PROTECTED] (Nathan Myers) writes:
> I.e. yes, Linux 2.4.0 and ext2 do implement the distinction.
> Sorry for the misinformation.
Okay ... meanwhile I've got to report the reverse: I've just confirmed
that on HPUX 10.20, there is *not* a distinction between fsync and
fdatasync. I was misle
On Sat, Feb 17, 2001 at 07:34:22PM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] (Nathan Myers) writes:
> > In the 2.4 kernel it says (fs/buffer.c)
>
> >/* this needs further work, at the moment it is identical to fsync() */
> >down(&inode->i_sem);
> >err = file->f_op->fsync(file, dentry
[EMAIL PROTECTED] (Nathan Myers) writes:
> In the 2.4 kernel it says (fs/buffer.c)
>/* this needs further work, at the moment it is identical to fsync() */
>down(&inode->i_sem);
>err = file->f_op->fsync(file, dentry);
>up(&inode->i_sem);
Hmm, that's the same code that's been ther
[EMAIL PROTECTED] (Nathan Myers) writes:
> Certainly there are machines and kernels that count time more precisely
> (isn't PG ported to QNX?). We do users of such kernels no favors by
> pretending they only count clock ticks. Furthermore, a 1ms clock
> tick is pretty common, e.g. on Alpha box
Matthew Kirkwood <[EMAIL PROTECTED]> writes:
> No options changed from defaults. (I'll look at
> that tomorrow -- is there anything worth changing other than
> commit_delay and fsync?)
-B for sure ... the default -B is way too small for WAL.
> Firstly, it looks like 2.4 is mixed news for heavy
On 17 Feb 2001 at 15:53 (-0800), Nathan Myers wrote:
| On Sat, Feb 17, 2001 at 06:30:12PM -0500, Brent Verner wrote:
| > On 17 Feb 2001 at 17:56 (-0500), Tom Lane wrote:
| >
| > [snipped]
| >
| > | Is anyone out there running a 2.4 Linux kernel? Would you try pgbench
| > | with current sources,
On Sat, Feb 17, 2001 at 06:30:12PM -0500, Brent Verner wrote:
> On 17 Feb 2001 at 17:56 (-0500), Tom Lane wrote:
>
> [snipped]
>
> | Is anyone out there running a 2.4 Linux kernel? Would you try pgbench
> | with current sources, commit_delay=0, -B at least 1024, no -F, and see
> | how the resul
On Sat, Feb 17, 2001 at 12:26:31PM -0500, Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > A comment on microsecond delays using select(). Most Unix kernels run
> > at 100hz, meaning that they have a programmable timer that interrupts
> > the CPU every 10 milliseconds.
>
> Right -
On 17 Feb 2001 at 17:56 (-0500), Tom Lane wrote:
[snipped]
| Is anyone out there running a 2.4 Linux kernel? Would you try pgbench
| with current sources, commit_delay=0, -B at least 1024, no -F, and see
| how the results change when pg_fsync is made to call fdatasync instead
| of fsync? (It's
Hi,
Not sure if anyone will find this of interest, but I ran
pgbench on my main Linux box to see what sort of performance
difference might be visible between 2.2 and 2.4 kernels.
Hardware: A dual P3-450 with 384Mb of RAM and 3 SCSI disks.
The pg datafiles live in a half-gig partition on the firs
On Sat, 17 Feb 2001, Tom Lane wrote:
> Another thing I am wondering about is why we're not using fdatasync(),
> where available, instead of fsync(). The whole point of preallocating
> the WAL files is to make fdatasync safe, no?
Linux/x86 fdatasync(2) manpage:
BUGS
Currently (Linux 2.0.
On Sat, Feb 17, 2001 at 03:45:30PM -0500, Bruce Momjian wrote:
> > Right now the WAL preallocation code (XLogFileInit) is not good enough
> > because it does lseek to the 16MB position and then writes 1 byte there.
> > On an implementation that supports holes in files (which is most Unixen)
> > th
Larry Rosenman <[EMAIL PROTECTED]> writes:
> I've written swap files and such with:
> dd if=/dev/zero of=SWAPFILE bs=512 count=204800
> and all the blocks are allocated.
I've also confirmed that writing zeroes is sufficient on HPUX (du
shows that the correct amount of space is allocated, unlike
> * Bruce Momjian <[EMAIL PROTECTED]> [010217 14:46]:
> > > Right now the WAL preallocation code (XLogFileInit) is not good enough
> > > because it does lseek to the 16MB position and then writes 1 byte there.
> > > On an implementation that supports holes in files (which is most Unixen)
> > > tha
* Bruce Momjian <[EMAIL PROTECTED]> [010217 14:50]:
> > * Bruce Momjian <[EMAIL PROTECTED]> [010217 14:46]:
> > > > Right now the WAL preallocation code (XLogFileInit) is not good enough
> > > > because it does lseek to the 16MB position and then writes 1 byte there.
> > > > On an implementation t
* Bruce Momjian <[EMAIL PROTECTED]> [010217 14:46]:
> > Right now the WAL preallocation code (XLogFileInit) is not good enough
> > because it does lseek to the 16MB position and then writes 1 byte there.
> > On an implementation that supports holes in files (which is most Unixen)
> > that doesn't
> Right now the WAL preallocation code (XLogFileInit) is not good enough
> because it does lseek to the 16MB position and then writes 1 byte there.
> On an implementation that supports holes in files (which is most Unixen)
> that doesn't cause physical allocation of the intervening space. We'd
>
On Sat, 17 Feb 2001, Tom Lane wrote:
> The Hermit Hacker <[EMAIL PROTECTED]> writes:
> > No way to group the writes to you can keep the most recent one open?
> > Don't see an easy way, do you?
> >>
> >> No, but I haven't looked at it. I am now much more concerned with the
> >> delay,
>
> I concu
On Sat, 17 Feb 2001, Bruce Momjian wrote:
> > > No, but I haven't looked at it. I am now much more concerned with the
> > > delay, and am wondering if I should start thinking about trying my idea
> > > of looking for near-committers and post the patch to the list to see if
> > > anyone likes it
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Another thing I am wondering about is why we're not using fdatasync(),
> where available, instead of fsync(). The whole point of preallocating
> the WAL files is to make fdatasync safe, no?
> Don't we have to fsync the inode too? Actually, I was hopin
> > Another thing I am wondering about is why we're not using fdatasync(),
> > where available, instead of fsync(). The whole point of preallocating
> > the WAL files is to make fdatasync safe, no?
>
> This still looks like it'd be a win, by reducing the number of seeks
> needed to complete a WA
> Actually ... take a close look at the code. The delay is done in
> xact.c between XLogInsert(commitrecord) and XLogFlush(). As near
> as I can tell, both the write() and the fsync() will happen in
> XLogFlush(). This means the delay is just plain broken: placed
> there, it cannot do anything
I wrote:
> Actually ... take a close look at the code. The delay is done in
> xact.c between XLogInsert(commitrecord) and XLogFlush(). As near
> as I can tell, both the write() and the fsync() will happen in
> XLogFlush(). This means the delay is just plain broken: placed
> there, it cannot do
Bruce Momjian <[EMAIL PROTECTED]> writes:
> With the delay, it looks like:
> time backend 1 backend 2
> - -
> 0 write()
> 1 sleep() write()
> 2 fsync() sleep()
> 3 fsync()
Actually ... take a close look a
> So *if* some I/O just completed, the call *might* do what we need,
> which is yield the CPU. Otherwise we're just wasting cycles, and
> will continue to waste them until we do a select with a nonzero
> delay. I propose we cut out the spinning and just do a nonzero delay
> immediately.
Well, a
Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Having read the select(2) man page more closely, I now realize that
>> it is *defined* not to yield the processor when the requested delay
>> is zero: it just checks the file ready status and returns immediately.
> Actually, a kernel call is something.
> > The easy fix is to just set the delay to zero. Looks like that will fix
> > most of the problem.
>
> Except that Vadim had a reason for setting it to 5, and I'm loath to see
> that changed unless someone actaully understands the ramifications other
> then increasing performance ...
See post
> I have been thinking some more about the s_lock() delay loop in
> connection with this. We currently have
>
> /*
> * Each time we busy spin we select the next element of this array as the
> * number of microseconds to wait. This accomplishes pseudo random back-off.
> * Values are not critic
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > A comment on microsecond delays using select(). Most Unix kernels run
> > at 100hz, meaning that they have a programmable timer that interrupts
> > the CPU every 10 milliseconds.
>
> Right --- this probably also explains my observation that some ke
I want to give some background on commit_delay, its initial purpose, and
possible options.
First, looking at the process that happens during a commit:
write() - copy WAL dirty page to kernel disk buffer
fsync() - force WAL kernel disk buffer to disk platter
fsync() take much lon
The Hermit Hacker <[EMAIL PROTECTED]> writes:
>> The easy fix is to just set the delay to zero. Looks like that will fix
>> most of the problem.
> Except that Vadim had a reason for setting it to 5,
He claimed to have seen better performance with a nonzero delay.
So far none of the rest of us h
Bruce Momjian <[EMAIL PROTECTED]> writes:
> A comment on microsecond delays using select(). Most Unix kernels run
> at 100hz, meaning that they have a programmable timer that interrupts
> the CPU every 10 milliseconds.
Right --- this probably also explains my observation that some kernels
seem t
On Sat, 17 Feb 2001, Bruce Momjian wrote:
> > >
> > > BTW, is 7.1 going to be a bit slower than 7.0? Or just Beta 5? Just
> > > curious. Don't mind waiting for 7.2 for the speed-up if necessary.
> >
> > It is possible that it will be ... the question is whether the slow down
> > is unbearable or
Bruce Momjian wrote:
> In fact, the kernel doesn't even contain have a way
> to measure microsecond timings.
Linux has patches available to do microsecond timings, but they're
nonportable, of course.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > The locale enabled regression results fail due to
> > currency format and collation errors. Diffs attached. I'm not sure I
> > understand the select_views failure, either. Locale used was en_US.
> The select_views delta looks like a
A comment on microsecond delays using select(). Most Unix kernels run
at 100hz, meaning that they have a programmable timer that interrupts
the CPU every 10 milliseconds. The kernel only gets to control the cpu
during those tick interrupts or if a user application makes a kernel
call.
Therefore
Lamar Owen <[EMAIL PROTECTED]> writes:
> The locale enabled regression results fail due to
> currency format and collation errors. Diffs attached. I'm not sure I
> understand the select_views failure, either. Locale used was en_US.
The select_views delta looks like a sort-order issue as well;
Ok, after Tatsuo and Peter have both said that building without locale
support should not use the locale support in the OS, and remembering my
6.5.3 experience of a year back, I decided to test it out completely.
And I am wrong with respect to 7.1beta4.
For 7.1beta4 disabling locale will indeed
* Tom Lane <[EMAIL PROTECTED]> [010216 22:49]:
> "Schmidt, Peter" <[EMAIL PROTECTED]> writes:
> > So, is it OK to use commit_delay=0?
>
> Certainly. In fact, I think that's about to become the default ;-)
>
> I have now experimented with several different platforms --- HPUX,
> FreeBSD, and two
The html docs should once again be generated automatically on
postgresql.org on a twice-daily basis. Thanks to Peter E for working me
through the toolset and configuration changes...
- Thomas
Ok, a bit late but ;-)
a few weeks ago I had an Advanced Java course, and the tutor actually
demonstrated the Python Corba interface.
Looked pretty good. He even showed JPython & corba (which is Python written
in Java).
Peter
At 11:24 08/02/01 +0100, Georges Martin wrote:
>On 7/02/01 at 18:0
lockhart> > ... See included png file.
lockhart>
lockhart> What kind of machine was this run on?
lockhart>
lockhart> - Thomas
Sorry to forget to mention about that.
SONY VAIO Z505CR/K (note PC)
Pentium III 750MHz/256MB memory/20GB IDE HDD
Linux (kernel 2.2.17)
configure --
42 matches
Mail list logo
