Shridhar Daithankar wrote:
Does 30% difference above count as significant?
No. It's Linux, we can look at the sources: there is no per-fd cache,
the page cache is global. Thus fsync() syncs the whole cache to disk.
A problem could only occur if the file cache is not global - perhaps a
per-nod
On Mon, Nov 17, 2003 at 12:46:34AM -0500, Bruce Momjian wrote:
> Tom Lane wrote:
> > > Do we know that having the background writer fsync a file that was
> > > written by a backend cause all the data to fsync? I think I could write
> > > a program to test this by timing each of these tests:
> >
>
On Monday 17 November 2003 11:16, Bruce Momjian wrote:
> Tom Lane wrote:
> > > Do we know that having the background writer fsync a file that was
> > > written by a backend cause all the data to fsync? I think I could
> > > write a program to test this by timing each of these tests:
> >
> > That m
Hannu Krosing wrote:
> Bruce Momjian kirjutas E, 17.11.2003 kell 03:58:
>
> >
> > OK, let me give you my logic and you can tell me where I am wrong.
> >
> > First, how many backend can a single write process support if all the
> > backends are doing insert/update/deletes? 5? 10? Let's assume
Bruce Momjian kirjutas E, 17.11.2003 kell 03:58:
>
> OK, let me give you my logic and you can tell me where I am wrong.
>
> First, how many backend can a single write process support if all the
> backends are doing insert/update/deletes? 5? 10? Let's assume 10.
> Second, once we change write
Tom Lane wrote:
> > Do we know that having the background writer fsync a file that was
> > written by a backend cause all the data to fsync? I think I could write
> > a program to test this by timing each of these tests:
>
> That might prove something about the particular platform you tested it
>
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Where am I wrong?
>
> I don't think any of this is relevant. There are a certain number of
> blocks we have to get down to disk before we can declare a transaction
> committed, and there are a certain number that we have to get down
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Where am I wrong?
I don't think any of this is relevant. There are a certain number of
blocks we have to get down to disk before we can declare a transaction
committed, and there are a certain number that we have to get down to
disk before we can declar
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Seriously though, if we can move the bulk of the writing work into
> >> background processes then I don't believe that there will be any
> >> significant penalty for regular backends.
>
> > If the background write
Jan Wieck <[EMAIL PROTECTED]> writes:
> Well, the bgwriter has basically the same chance the checkpointer has
> ... mdblindwrt() in the end, because he doesn't have the relcache handy.
We could easily get rid of mdblindwrt --- there is no very good reason
that we use the relcache for I/O. There
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
Removing sync() entirely requires very accurate fsync()'ing in the
background writer, the checkpointer and the backends. Basically none of
them can mark a block "clean" if he fails to fsync() the relation later!
This will be a mess to code.
Jan Wieck <[EMAIL PROTECTED]> writes:
> Removing sync() entirely requires very accurate fsync()'ing in the
> background writer, the checkpointer and the backends. Basically none of
> them can mark a block "clean" if he fails to fsync() the relation later!
> This will be a mess to code.
Not real
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Tom Lane wrote:
Seriously though, if we can move the bulk of the writing work into
background processes then I don't believe that there will be any
significant penalty for regular backends.
If the background writer starts using fsync(), we
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Seriously though, if we can move the bulk of the writing work into
>> background processes then I don't believe that there will be any
>> significant penalty for regular backends.
> If the background writer starts using fsync(), we can
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> One reason I like the idea of adopting a sync-when-you-write policy is
> >> that it eliminates the need for anything as messy as that.
>
> > Yes, but can we do it without causing a performance degredation, and I
>
Manfred Spraul wrote:
Tom Lane wrote:
Seriously though, if we can move the bulk of the writing work into
background processes then I don't believe that there will be any
significant penalty for regular backends. And I believe that it would
be a huge advantage from a correctness point of view i
Manfred Spraul <[EMAIL PROTECTED]> writes:
> Which function guarantees that renames of WAL files arrived on the disk?
The OS itself is supposed to guarantee that; that's what a journaling
file system is for. In any case, I don't think we care. Renaming would
apply only to WAL segments that are
Tom Lane wrote:
Seriously though, if we can move the bulk of the writing work into
background processes then I don't believe that there will be any
significant penalty for regular backends. And I believe that it would
be a huge advantage from a correctness point of view if we could stop
depending
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> One reason I like the idea of adopting a sync-when-you-write policy is
>> that it eliminates the need for anything as messy as that.
> Yes, but can we do it without causing a performance degredation, and I
> would hate to change someth
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Not sure how we are going to do this in Win32, but somehow we will have
> > to record all open files between checkpoints in an area that the
> > checkpoint process can read during a checkpoint.
>
> One reason I like the idea of adopti
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Not sure how we are going to do this in Win32, but somehow we will have
> to record all open files between checkpoints in an area that the
> checkpoint process can read during a checkpoint.
One reason I like the idea of adopting a sync-when-you-write pol
Here is the SRA sync() code for Win32. As you might know, fsync on
Win32 is _commit, and sync() is _flushall. However, _flushall only
flushes only _open_ kernel buffers, not dirty buffers that have been
closed. Therefore, on Win32, during checkpoint, you have to open,
fsync(_commit), close all f
22 matches
Mail list logo
