pg_standby could not open wal file after selecting new timeline

Dave Cramer <pg@fastcrypt.com> writes:

2008-11-05 11:43:45 EST [14853] LOG: selected new timeline ID: 4
2008-11-05 11:43:45 EST [14853] LOG: archive recovery complete
2008-11-05 11:43:48 EST [14853] FATAL: could not open file "pg_xlog/
00000004000016ED0000007F" (log file 5869, segment 127): Invalid argument

"Invalid argument"?? On the platforms I have handy, the only documented
reason for open(2) to fail with EINVAL is illegal value of the flags
argument, which should be impossible. What platform is this and what
wal_sync_method are you using?

regards, tom lane

Tom,

On 5-Nov-08, at 12:21 PM, Tom Lane wrote:

nvalid argument"?? On the platforms I have handy, the only documented
reason for open(2) to fail with EINVAL is illegal value of the flags
argument, which should be impossible. What platform is this and what
wal_sync_method are you using?

Red Hat Enterprise Linux Server release 5.2 (Tikanga)

wal_sync method is open_sync
Thing is the server is running off of a ramdisk for the move (very
temporarily)

Dave

Dave Cramer <pg@fastcrypt.com> writes:

On 5-Nov-08, at 12:21 PM, Tom Lane wrote:

nvalid argument"?? On the platforms I have handy, the only documented
reason for open(2) to fail with EINVAL is illegal value of the flags
argument, which should be impossible. What platform is this and what
wal_sync_method are you using?

Red Hat Enterprise Linux Server release 5.2 (Tikanga)

wal_sync method is open_sync
Thing is the server is running off of a ramdisk for the move (very
temporarily)

Huh, is it possible that Linux rejects O_SYNC for a file on ramdisk?
I guess I could see an argument for doing that but it seems a tad
anal-retentive. Try setting fsync = off and see what happens.

regards, tom lane

I wrote:

Huh, is it possible that Linux rejects O_SYNC for a file on ramdisk?

I found this in the Fedora 9 manpage for open(2):

O_DIRECT support was added under Linux in kernel version 2.4.10. Older
Linux kernels simply ignore this flag. Some filesystems may not imple-
ment the flag and open() will fail with EINVAL if it is used.

so it may not be ramdisk per se that's the issue, but the filesystem
you're using on it.

We set O_DIRECT along with O_SYNC whenever O_DIRECT is defined. I
wonder whether there's a need to make that decision more configurable.

regards, tom lane

On 5-Nov-08, at 1:00 PM, Tom Lane wrote:

I wrote:

Huh, is it possible that Linux rejects O_SYNC for a file on ramdisk?

I found this in the Fedora 9 manpage for open(2):

O_DIRECT support was added under Linux in kernel version
2.4.10. Older
Linux kernels simply ignore this flag. Some filesystems may
not imple-
ment the flag and open() will fail with EINVAL if it is used.

so it may not be ramdisk per se that's the issue, but the filesystem
you're using on it.

We set O_DIRECT along with O_SYNC whenever O_DIRECT is defined. I
wonder whether there's a need to make that decision more configurable.

fsync=off works fine if that helps