On Sun, 21 Aug 2005 19:27:35 -0500
"Jim C. Nasby" <[EMAIL PROTECTED]> wrote:
> On Mon, Aug 08, 2005 at 07:45:38PM -0400, Andrew Dunstan wrote:
> > So the short answer is possibly "You build the tests and we'll run 'em."
>
> Would some version of dbt2/3 work for this?
Yeah, trying... On the larg
On Mon, Aug 08, 2005 at 07:45:38PM -0400, Andrew Dunstan wrote:
> So the short answer is possibly "You build the tests and we'll run 'em."
Would some version of dbt2/3 work for this?
--
Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED]
Pervasive Softwarehttp://pervasive.com
UFS was the filesystem on the Solaris 9 box.
--
Thomas F. O'Connell
Co-Founder, Information Architect
Sitening, LLC
Strategic Open Source: Open Your i™
http://www.sitening.com/
110 30th Avenue North, Suite 6
Nashville, TN 37203-6320
615-469-5150
615-469-5151 (fax)
On Aug 11, 2005, at 4:18 PM,
On Wed, Aug 10, 2005 at 02:11:48AM -0500, Thomas F. O'Connell wrote:
> I was recently witness to a benchmark of 7.4.5 on Solaris 9 wherein
> it was apparently demonstrated that fsync was the fastest option
> among the 7.4.x wal_sync_method options.
>
> If there's a way to make this information
On 2005-08-10, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>>> If a SCSI drive reports write complete when it hasn't actually put the
>>> bits on the platter yet, then it's simply broken.
>
>> I guess you haven't read the spec much, then.
>
> [ shrug... ] I
I was recently witness to a benchmark of 7.4.5 on Solaris 9 wherein
it was apparently demonstrated that fsync was the fastest option
among the 7.4.x wal_sync_method options.
If there's a way to make this information more useful by providing
more data, please let me know, and I'll see what I
On 8/9/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Personally, my only complaint regarding either choice is the
> assumption that a 'WIN32' guy is stupid, and that 'WIN32' itself is
> deficient. As long as the default is well documented, I don't have a
> problem with either 'faster but less
On Tue, Aug 09, 2005 at 11:01:36PM -0400, Tom Lane wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
> >> If a SCSI drive reports write complete when it hasn't actually put the
> >> bits on the platter yet, then it's simply broken.
> > I guess you haven't read the spec much, then.
> [ shrug..
Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> If a SCSI drive reports write complete when it hasn't actually put the
>> bits on the platter yet, then it's simply broken.
> I guess you haven't read the spec much, then.
[ shrug... ] I have seen that spec before: I was making a living by
implem
On 2005-08-09, Tom Lane <[EMAIL PROTECTED]> wrote:
> Andrew - Supernews <[EMAIL PROTECTED]> writes:
>> On 2005-08-09, "Magnus Hagander" <[EMAIL PROTECTED]> wrote:
>>> ... or iDE disks with write cache enabled. I've certainly seen more than
>>> what I'd call 1% (though I haven't studied it to be sur
Andrew - Supernews <[EMAIL PROTECTED]> writes:
> On 2005-08-09, "Magnus Hagander" <[EMAIL PROTECTED]> wrote:
>> ... or iDE disks with write cache enabled. I've certainly seen more than
>> what I'd call 1% (though I haven't studied it to be sure) that's because
>> of write-cached disks...
> Every S
On 2005-08-09, "Magnus Hagander" <[EMAIL PROTECTED]> wrote:
> ... or iDE disks with write cache enabled. I've certainly seen more than
> what I'd call 1% (though I haven't studied it to be sure) that's because
> of write-cached disks...
Every SCSI disk I've looked at recently has had write cache e
> > > Now thinking about it, the guy had corrupt table, not WAL log.
> > > How is WAL->tables synched? Does the 'wal_sync_method'
> > > affect it or not?
> >
> > I *think* it always fsyncs() there as it is now, but I'm
> not 100% sure.
>
> wal_sync_method is also used to flush pages during a
Magnus Hagander wrote:
> > > > Now thinking about it, the guy had corrupt table, not WAL log.
> > > > How is WAL->tables synched? Does the 'wal_sync_method'
> > > > affect it or not?
> > >
> > > I *think* it always fsyncs() there as it is now, but I'm
> > not 100% sure.
> >
> > wal_sync_method
Magnus Hagander wrote:
> > > I dunno about workstation OS, but on the server OSes it certainly
> > > isn't default.
> >
> > At least on XP Pro it is default.
>
> Yuck.
I see "enable write caching" as enabled by default on my XP Pro laptop,
though laptops can be said to already have battery-back
Magnus Hagander wrote:
> > Now thinking about it, the guy had corrupt table, not WAL log.
> > How is WAL->tables synched? Does the 'wal_sync_method'
> > affect it or not?
>
> I *think* it always fsyncs() there as it is now, but I'm not 100% sure.
wal_sync_method is also used to flush pages duri
On Tue, Aug 09, 2005 at 12:25:36PM +0300, Marko Kreen wrote:
> On Tue, Aug 09, 2005 at 10:08:25AM +0200, Magnus Hagander wrote:
> > Most filesystem corruptions that happen on windows are because people
> > enable write caching on drives without battery backup. The same issue
> > we're facing here,
On Tue, Aug 09, 2005 at 04:05:28PM +0200, Magnus Hagander wrote:
> > > > Now thinking about it, the guy had corrupt table, not WAL log.
> > > > How is WAL->tables synched? Does the 'wal_sync_method'
> > > > affect it or not?
> > >
> > > I *think* it always fsyncs() there as it is now, but I'm
>
> > > Now thinking about it, the guy had corrupt table, not WAL log.
> > > How is WAL->tables synched? Does the 'wal_sync_method'
> > > affect it or not?
> >
> > I *think* it always fsyncs() there as it is now, but I'm
> not 100% sure.
>
> No. If fsync is off, then no fsync is done to the dat
On Tue, Aug 09, 2005 at 12:58:31PM +0200, Magnus Hagander wrote:
> > Now thinking about it, the guy had corrupt table, not WAL log.
> > How is WAL->tables synched? Does the 'wal_sync_method'
> > affect it or not?
>
> I *think* it always fsyncs() there as it is now, but I'm not 100% sure.
No.
> > I dunno about workstation OS, but on the server OSes it certainly
> > isn't default.
>
> At least on XP Pro it is default.
Yuck.
> > > The professional probably tests it on his own desktop. I don't
> > > think PostgreSQL reaches the data center before passing
> the run on
> > > desktop
On Tue, Aug 09, 2005 at 12:14:09PM +0200, Magnus Hagander wrote:
> > > That can definitly be debated. Properly maintaned on proper
> > hardware,
> > > it's quite reliable these days.
> > > Most filesystem corruptions that happen on windows are
> > because people
> > > enable write caching on dr
> > That can definitly be debated. Properly maintaned on proper
> hardware,
> > it's quite reliable these days.
> > Most filesystem corruptions that happen on windows are
> because people
> > enable write caching on drives without battery backup. The
> same issue
> > we're facing here, it's *
On Tue, Aug 09, 2005 at 10:08:25AM +0200, Magnus Hagander wrote:
> That can definitly be debated. Properly maintaned on proper hardware,
> it's quite reliable these days.
> Most filesystem corruptions that happen on windows are because people
> enable write caching on drives without battery backup.
On Tue, Aug 09, 2005 at 10:02:44AM +0200, Magnus Hagander wrote:
> > > It behaves the same on Unix as Win32, and if you have
> > battery-backed
> > > cache, you don't need writethrough, so we don't have it as
> > default. I
>
> Correction, if you have bbwc, you *should not* have writethrough.
> > > Also, why can't win32 be safe without battery-backed cache?
> > > I can't see such requirement on other platforms.
> >
> > It can, you just need to learn how to configure your
> system. There are
> > two different options to make it safe on win32 without
> battery backed
> > cache:
>
> I
> > > I think we should offer the reliable option by default,
> and mention
> > > the fast option for those who have battery-backed cache
> in the manual.
> >
> > But only on Win32?
>
> We should do what's possible with what's given to us.
>
> On Win32:
>
> 1. We can write through cache.
Y
On Mon, Aug 08, 2005 at 08:04:44PM -0400, Tom Lane wrote:
> Bruce Momjian writes:
> > Marko Kreen wrote:
> >> On same topic:
> >> http://archives.postgresql.org/pgsql-general/2005-07/msg00811.php
> >> Why does win32 PostgreSQL allow data corruption by default?
>
> > It behaves the same on Unix as
> > > > Currently, here are the options available for wal_sync_method:
> > > >
> > > > #wal_sync_method = fsync# the default
> varies across platforms:
> > > > # fsync,
> fdatasync, fsync_writethrough,
> > > >
Bruce Momjian writes:
> My proposal is to remove fdatasync and open_datasync, and have have
> fsync _prefer_ fdatasync, and open_sync prefer open_datastync, but fall
> back to fsync and open_sync if the *data* version are not supported.
And this will buy us what, other than lack of flexibility?
Tom Lane wrote:
> Bruce Momjian writes:
> > My proposal is to remove fdatasync and open_datasync, and have have
> > fsync _prefer_ fdatasync, and open_sync prefer open_datastync, but fall
> > back to fsync and open_sync if the *data* version are not supported.
>
> And this will buy us what, othe
Tom Lane wrote:
> Bruce Momjian writes:
> > Marko Kreen wrote:
> >> On same topic:
> >> http://archives.postgresql.org/pgsql-general/2005-07/msg00811.php
> >> Why does win32 PostgreSQL allow data corruption by default?
>
> > It behaves the same on Unix as Win32, and if you have battery-backed
> >
Tom Lane wrote:
> Bruce Momjian writes:
> > No one is every going to do it, so we might as well make the best guess
> > we have. I think any platform where the *data* options are slower than
> > the non-*data* options is broken, and if that logic holds, we might as
> > well just use *data* by def
On Mon, 2005-08-08 at 17:03 -0400, Tom Lane wrote:
>
> That's a decision that hasn't got a shred of evidence to justify
> imposing it on every platform.
This option has its uses on Linux, however. In my testing it's good for
a large speedup (20%) on a 10-client pgbench, and a minor improvement
w
Bruce Momjian writes:
>> fsync_writethrough only works on Win32 the postgresql.conf should
>> reflect that.
> Right now what wal_sync_method supports isn't clear at all.
Yeah. I think we had a TODO to figure out a way for the assign_hook to
report back exactly which values *are* allowed on the
Joshua D. Drake wrote:
>
> >>>I think we should offer the reliable option by default, and mention the
> >>>fast option for those who have battery-backed cache in the manual.
> >>
> >>But only on Win32?
> >
> >
> > Yes, because that's the only place where that option works, right?
>
> fsync_writ
Tom Lane said:
> Kris Jurka <[EMAIL PROTECTED]> writes:
>> Automated performance testing seems like a bad idea for the buildfarm.
>> Consider in my particular case I've got three members that all
>> happen to be running in virtual machines on the same host. What
>> virtualization does for perf
Kris Jurka <[EMAIL PROTECTED]> writes:
> Automated performance testing seems like a bad idea for the buildfarm.
> Consider in my particular case I've got three members that all happen to
> be running in virtual machines on the same host. What virtualization does
> for performance and what happ
Tom Lane wrote:
Andrew Dunstan <[EMAIL PROTECTED]> writes:
So the short answer is possibly "You build the tests and we'll run 'em."
The availability of the buildfarm certainly makes it a lot more feasible
to do performance tests on a variety of platforms. So, who wants to
knock som
On Mon, 8 Aug 2005, Andrew Dunstan wrote:
> So the short answer is possibly "You build the tests and we'll run 'em."
>
Automated performance testing seems like a bad idea for the buildfarm.
Consider in my particular case I've got three members that all happen to
be running in virtual machin
Bruce Momjian writes:
> Marko Kreen wrote:
>> On same topic:
>> http://archives.postgresql.org/pgsql-general/2005-07/msg00811.php
>> Why does win32 PostgreSQL allow data corruption by default?
> It behaves the same on Unix as Win32, and if you have battery-backed
> cache, you don't need writethro
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> So the short answer is possibly "You build the tests and we'll run 'em."
The availability of the buildfarm certainly makes it a lot more feasible
to do performance tests on a variety of platforms. So, who wants to
knock something together?
I suppose w
Simon Riggs wrote:
On Mon, 2005-08-08 at 17:44 -0400, Bruce Momjian wrote:
In summary, we added all those wal_sync_method values in hopes of
getting some data on which is best on which platform, but having gone
several years with few reports, I am thinking we should just choose the
best on
Bruce Momjian writes:
> No one is every going to do it, so we might as well make the best guess
> we have. I think any platform where the *data* options are slower than
> the non-*data* options is broken, and if that logic holds, we might as
> well just use *data* by default if we can, which is m
On Mon, 2005-08-08 at 17:44 -0400, Bruce Momjian wrote:
> In summary, we added all those wal_sync_method values in hopes of
> getting some data on which is best on which platform, but having gone
> several years with few reports, I am thinking we should just choose the
> best ones we can and move o
I think we should offer the reliable option by default, and mention the
fast option for those who have battery-backed cache in the manual.
But only on Win32?
Yes, because that's the only place where that option works, right?
fsync_writethrough only works on Win32 the postgresql.conf shoul
Bruce,
> No one is every going to do it, so we might as well make the best guess
> we have. I think any platform where the *data* options are slower than
> the non-*data* options is broken, and if that logic holds, we might as
> well just use *data* by default if we can, which is my proposal.
Ch
On Mon, Aug 08, 2005 at 03:10:54PM -0700, Josh Berkus wrote:
> Marko,
> > Also, why can't win32 be safe without battery-backed cache?
> > I can't see such requirement on other platforms.
>
> Read the referenced message again. It's only an issue if you want to use
> open_datasync. fsync_writet
On Mon, Aug 08, 2005 at 06:02:37PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > I think we should offer the reliable option by default, and mention the
> > fast option for those who have battery-backed cache in the manual.
>
> But only on Win32?
We should do what's possible with what's
On Mon, Aug 08, 2005 at 06:02:37PM -0400, Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > On Mon, Aug 08, 2005 at 05:38:59PM -0400, Bruce Momjian wrote:
> > > Marko Kreen wrote:
> > > > On Mon, Aug 08, 2005 at 03:56:39PM -0400, Bruce Momjian wrote:
> > > > > Currently, here are the options availab
Marko,
> Also, why can't win32 be safe without battery-backed cache?
> I can't see such requirement on other platforms.
Read the referenced message again. It's only an issue if you want to use
open_datasync. fsync_writethrough should be safe.
--
--Josh
Josh Berkus
Aglio Database Solutions
Marko Kreen wrote:
> On Mon, Aug 08, 2005 at 05:38:59PM -0400, Bruce Momjian wrote:
> > Marko Kreen wrote:
> > > On Mon, Aug 08, 2005 at 03:56:39PM -0400, Bruce Momjian wrote:
> > > > Currently, here are the options available for wal_sync_method:
> > > >
> > > > #wal_sync_method = fsync
Alvaro Herrera wrote:
> On Mon, Aug 08, 2005 at 05:38:59PM -0400, Bruce Momjian wrote:
> > Marko Kreen wrote:
> > > On Mon, Aug 08, 2005 at 03:56:39PM -0400, Bruce Momjian wrote:
> > > > Currently, here are the options available for wal_sync_method:
> > > >
> > > > #wal_sync_method = fsync
On Mon, Aug 08, 2005 at 05:38:59PM -0400, Bruce Momjian wrote:
> Marko Kreen wrote:
> > On Mon, Aug 08, 2005 at 03:56:39PM -0400, Bruce Momjian wrote:
> > > Currently, here are the options available for wal_sync_method:
> > >
> > > #wal_sync_method = fsync# the default varies across plat
In summary, we added all those wal_sync_method values in hopes of
getting some data on which is best on which platform, but having gone
several years with few reports, I am thinking we should just choose the
best ones we can and move on, rather than expose a confusing API to the
users.
Does anyon
Marko Kreen wrote:
> On Mon, Aug 08, 2005 at 03:56:39PM -0400, Bruce Momjian wrote:
> > Currently, here are the options available for wal_sync_method:
> >
> > #wal_sync_method = fsync# the default varies across platforms:
> > # fsync, fdatasync, fsyn
Tom Lane wrote:
> Bruce Momjian writes:
> > Currently, here are the options available for wal_sync_method:
> > #wal_sync_method = fsync# the default varies across platforms:
> > # fsync, fdatasync, fsync_writethrough,
> >
Bruce Momjian writes:
> Currently, here are the options available for wal_sync_method:
> #wal_sync_method = fsync# the default varies across platforms:
> # fsync, fdatasync, fsync_writethrough,
> # open_sync,
On Mon, Aug 08, 2005 at 03:56:39PM -0400, Bruce Momjian wrote:
> Currently, here are the options available for wal_sync_method:
>
> #wal_sync_method = fsync# the default varies across platforms:
> # fsync, fdatasync, fsync_writethrough,
>
59 matches
Mail list logo
