CVSROOT:/cvsroot
Module name:pgsql-server
Changes by: [EMAIL PROTECTED] 04/02/03 21:24:54
Modified files:
src/backend/storage/buffer: bufmgr.c
src/backend/utils/misc: guc.c postgresql.conf.sample
src/include/storage: bufmgr.h
Log message:
B
CVSROOT:/cvsroot
Module name:pgsql-server
Changes by: [EMAIL PROTECTED] 04/01/30 11:57:04
Modified files:
src/backend/storage/buffer: bufmgr.c
src/include: miscadmin.h
Log message:
Remove sleep() and use single PG_SLEEP call for Win32 signal han
Jan Wieck wrote:
> Tom Lane wrote:
>
> > [EMAIL PROTECTED] (Jan Wieck) writes:
> >>Added GUC variable bgwriter_flush_method controlling the action
> >>done by the background writer between writing dirty blocks and
> >>napping.
> >
> >>none (default) no action
> >>sync
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > Now doing fsync() or fdatasync() of possibly dozens of files in a row,
> > forcing the kernel to do one scattered file after another, letting the
> > disk heads dance like step-chicken on a hot tin ... that will be an
> > improvement, o
On Jan 27, 2004, at 6:25 PM, Tom Lane wrote:
Perhaps more to the point: all this is predicated on an assumption no
longer particularly valid, which is that the kernel's ideas about disk
write scheduling matter at all. A decent SCSI disk drive will pre-empt
the kernel's ideas anyway by absorbing as
Jan Wieck <[EMAIL PROTECTED]> writes:
> Now doing fsync() or fdatasync() of possibly dozens of files in a row,
> forcing the kernel to do one scattered file after another, letting the
> disk heads dance like step-chicken on a hot tin ... that will be an
> improvement, oh boy.
I'm not convinced
Bruce Momjian wrote:
I guess my major problem with moving away from sync is similar to the
reason we don't do raw devices --- sync is best done in the kernel and
disk driver that knows more about how to do it efficiently. I haven't
see any non-sync solution with performance similar to sync(). Ho
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> Not necessarily --- it could be out-of-disk-space, on at least some
> >> filesystems. More to the point, the important thing is not to commit a
>
> > I assume the operating system is already allocating file syste
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> Not necessarily --- it could be out-of-disk-space, on at least some
>> filesystems. More to the point, the important thing is not to commit a
> I assume the operating system is already allocating file system space
> during the write,
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> As I've said before, I think we need to find a way to stop using sync()
> >> altogether --- we have to move to fsync or O_SYNC and variants. sync
> >> has simply got the wrong API.
>
> > If sync failes (kernel to
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Tom Lane wrote:
> >> As I've said before, I think we need to find a way to stop using sync()
> >> altogether --- we have to move to fsync or O_SYNC and variants. sync
> >> has simply got the wrong API.
>
> > If sync failes (kernel to
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> As I've said before, I think we need to find a way to stop using sync()
>> altogether --- we have to move to fsync or O_SYNC and variants. sync
>> has simply got the wrong API.
> If sync failes (kernel to disk write failes) we have a
Jan Wieck wrote:
> Tom Lane wrote:
>
> > Jan Wieck <[EMAIL PROTECTED]> writes:
>
> >> The whole point of the bgwriter is to give responsetimes a better
> >> variance, I never claimed that it will improve performance.
> >
> > I want to use it to improve reliability, by getting rid of our
> > dep
Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > So far nobody bothered to make any other proposal how to cause the
> > kernel to actually do some writing at all. A lot of people babble about
> > fsync(), fdatasync() and fadvise and whatnot. A week ago I posted the
> > proposal for th
Jan Wieck wrote:
> Tom Lane wrote:
>
> > [EMAIL PROTECTED] (Jan Wieck) writes:
> >>Added GUC variable bgwriter_flush_method controlling the action
> >>done by the background writer between writing dirty blocks and
> >>napping.
> >
> >>none (default) no action
> >>sync
Tom Lane wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
The whole point of the bgwriter is to give responsetimes a better
variance, I never claimed that it will improve performance.
I want to use it to improve reliability, by getting rid of our
dependence on sync(). The bgwriter can afford to wai
On Sat, 24 Jan 2004, Tom Lane wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
> > So far nobody bothered to make any other proposal how to cause the
> > kernel to actually do some writing at all. A lot of people babble about
> > fsync(), fdatasync() and fadvise and whatnot. A week ago I posted the
Jan Wieck <[EMAIL PROTECTED]> writes:
> So far nobody bothered to make any other proposal how to cause the
> kernel to actually do some writing at all. A lot of people babble about
> fsync(), fdatasync() and fadvise and whatnot. A week ago I posted the
> proposal for this and got exactly zero re
Tom Lane wrote:
[EMAIL PROTECTED] (Jan Wieck) writes:
Added GUC variable bgwriter_flush_method controlling the action
done by the background writer between writing dirty blocks and
napping.
none (default) no action
sync bgwriter calls
[EMAIL PROTECTED] (Jan Wieck) writes:
> Added GUC variable bgwriter_flush_method controlling the action
> done by the background writer between writing dirty blocks and
> napping.
> none (default) no action
> sync bgwriter calls smgrsync() causin
CVSROOT:/cvsroot
Module name:pgsql-server
Changes by: [EMAIL PROTECTED] 04/01/24 16:00:46
Modified files:
src/backend/storage/buffer: bufmgr.c
src/backend/utils/misc: guc.c postgresql.conf.sample
src/include/storage: bufmgr.h
Log message:
A
21 matches
Mail list logo
