On 11/30/2010 11:17 PM, Tom Lane wrote:
Andrew Dunstan<and...@dunslane.net> writes:
On 11/30/2010 10:09 PM, Tom Lane wrote:
We should wait for the outcome of the discussion about whether to change
the default wal_sync_method before worrying about this.
we've just had a significant PGX customer encounter this with the latest
Postgres on Redhat's freshly released flagship product. Presumably the
default wal_sync_method will only change prospectively.
I don't think so. The fact that Linux is changing underneath us is a
compelling reason for back-patching a change here. Our older branches
still have to be able to run on modern OS versions. I'm also fairly
unclear on what you think a fix would look like if it's not effectively
a change in the default.
(Hint: this *will* be changing, one way or another, in Red Hat's version
of 8.4, since that's what RH is shipping in RHEL6.)
Well, my initial idea was that if PG_O_DIRECT is non-zero, we should
test at startup time if we can use it on the WAL file system and inhibit
its use if not.
Incidentally, I notice it's not used at all in test_fsync.c - should it
not be?
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
