Re: fsync-pgdata-on-recovery tries to write to more files than previously

On Fri, May 29, 2015 at 5:01 PM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> On Fri, May 29, 2015 at 9:25 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>
>>
>> Speaking of which, could somebody test that the committed patch does
>> what it's supposed to on Windows? You were worried upthread about
>> whether the tests for symlinks (aka junction points) behaved correctly,
>> and I have no way to check that either.
>>
>
> I have done some tests for the committed patch for this issue
> (especially to check the behaviour of symlink tests in the
> new code) on Windows - 7 and below are results:
>
> Test symlink for pg_xlog
> -------------------------------------
> Test -1 - Junction point for pg_xlog
> 1. Create a database (initdb)
> 2. Start server and forcefully crash it
> 3. cp E:\PGData\pg_xlog E:\TempLog\xlog_symlink_loc
> 4. mv E:\PGData\pg_xlog E:\bak_pg_xlog
> 5. Created a directory junction (equivalent symlink)
> mklink /J E:\ PGData\pg_xlog E:\TempLog\xlog_symlink_loc
> 6. Restart Server - operation is successful.
> I have debugged this operation, it does what it suppose to do,
> detects the junction point and does fsync.
>
> 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.
>
> Test-3 - Symlinks in pg_tblspc.
> 1. Create couple of tablespaces which creates symlinks
> in pg_tblspc
> 2. Crash the server
> 3. Restart Server - It works fine.
>
> I am not sure Test-2 is a valid thing and we should support it or
> not, but the current patch is sane w.r.t that form of symlinks
> as well.

It is always good to check, but is that relevant to the bug fixed? I
mean, you need to symlink a file in PGDATA that server has no write
permission on... For example tablespaces can be written to in test 3,
so that would work even with 9.4.2 after crashing the server with -m
immediate.
--
Michael