Re: fsync-pgdata-on-recovery tries to write to more files than previously
От | Tom Lane |
---|---|
Тема | Re: fsync-pgdata-on-recovery tries to write to more files than previously |
Дата | |
Msg-id | 28511.1432909404@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: fsync-pgdata-on-recovery tries to write to more files than previously (Michael Paquier <michael.paquier@gmail.com>) |
Список | pgsql-hackers |
Michael Paquier <michael.paquier@gmail.com> writes: > On Fri, May 29, 2015 at 6:49 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> Test - 2 - Directory Symlink for pg_xlog >> First 4 steps are same as Test-1 >> 5. mklink /D E:\ PGData\pg_xlog E:\TempLog\xlog_symlink_loc >> 6. Restart Server - Error >> - FATAL: required WAL directory "pg_xlog" does not exist >> This error occurs in >> ValidateXLOGDirectoryStructure()->stat(XLOGDIR, &stat_buf) >> 7. If I manually step-through that line, it proceeds and in >> SyncDataDirectory(), it detects the symlink; >> 8. After that in SyncDataDirectory(), when it does walkdir for >> datadir, for ./pg_xlog it reports the log message and then >> proceeds normal and the server is started. > Regarding this test, I just tested initdb -X and it works correctly > after crashing the server, so there is at least a workaround for the > error you are triggering here. Now, shouldn't we improve things as > well with mklink? That's a rather narrow case and we have a workaround > for it at initialization with initdb. I haven't looked much at the > code so I don't have a patch at hand but thoughts on this matter are > welcome. My (vague) recollection is that what mklink creates is not the same as a junction point and we intentionally only support the latter as pseudo-symlinks. You'd need to trawl the archives for more detail, unless someone else remembers. So I think we're good here. Thanks for all the testing! regards, tom lane
В списке pgsql-hackers по дате отправления: