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 larger system
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 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... ] I have
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
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
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 have seen that
Currently, here are the options available for wal_sync_method:
#wal_sync_method = fsync# the default
varies across platforms:
# fsync,
fdatasync, fsync_writethrough,
#
On Mon, Aug 08, 2005 at 08:04:44PM -0400, Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
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.
Yes.
2. We have
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 personally do
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. Not
only
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.
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 *not* a
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 drives without
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.
I can't
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. If fsync
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 data files
on
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
not 100% sure.
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, it's
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 during a
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-backed disks.
--
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
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
checkpoint, so
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 enabled
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 SCSI disk I've
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 sure) that's
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
implementing
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, open_datasync
I don't
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,
Bruce Momjian pgman@candle.pha.pa.us writes:
Currently, here are the options available for wal_sync_method:
#wal_sync_method = fsync# the default varies across platforms:
# fsync, fdatasync, fsync_writethrough,
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us writes:
Currently, here are the options available for wal_sync_method:
#wal_sync_method = fsync# the default varies across platforms:
# fsync, fdatasync, fsync_writethrough,
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,
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
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 platforms:
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# the
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# the
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
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 available for
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 given
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_writethrough
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.
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
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 on,
Bruce Momjian pgman@candle.pha.pa.us 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
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
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 we
Bruce Momjian pgman@candle.pha.pa.us 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
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 machines
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
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 happens
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 performance
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_writethrough only works on
Bruce Momjian pgman@candle.pha.pa.us 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
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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Tom Lane wrote:
Bruce Momjian pgman@candle.pha.pa.us 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
Bruce Momjian pgman@candle.pha.pa.us 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
60 matches
Mail list logo
