On Thu, 30 Jun 2005, Tom Lane wrote:
Jeff Frost <[EMAIL PROTECTED]> writes:
I'll have to retest that particular scenario and verify that something
else was not causing the problem when I have a chance now that I have
a fully functional and scripted out base backup and recover solution;
however, it did not give me any of the errors I see when my
walrestore.sh script cannot access an archived wal, so I would believe
it did not even try to get it out of the archive.
Tom,
Finally got a chance to give this another full test and discovered that the
WAL files work fine in the archive dir, but I uncovered a different problem.
What had happened was that when I rsynced the walarchive and walrestore
scripts over to the server, rsync made them mode 644 as they were in my cvs
sandbox and thus not executable. When postgres went to call the script, I
guess it stat'd the walrestore, saw that it was not executable and quietly
reported that it could not find the WAL file in the pg_xlog dir. Would
probably be handy to throw a warning that the restore command was not
executable, no? Sorry for the false alarm before.
--
Jeff Frost, Owner <[EMAIL PROTECTED]>
Frost Consulting, LLC http://www.frostconsultingllc.com/
Phone: 650-780-7908 FAX: 650-649-1954
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
