Re: fsync-pgdata-on-recovery tries to write to more files than previously - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: fsync-pgdata-on-recovery tries to write to more files than previously
Date
Msg-id CAA4eK1Kes+yCqLbVzSRkHrVcMEaUCkuRsuA10V105KbrYXFxKQ@mail.gmail.com
Whole thread Raw
In response to Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: fsync-pgdata-on-recovery tries to write to more files than previously
List pgsql-hackers
On Fri, May 29, 2015 at 2:28 PM, Michael Paquier <michael.paquier@gmail.com> wrote:
>
> On Fri, May 29, 2015 at 5:01 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > 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.

I have just tried to cover the paths which has symlink related code
in the new commit (in functions SyncDataDirectory() and walkdir()),
because thats what I understood from Tom's mail.  Without test-3, it
won't cover walkdir symlink test path, I didn't knew that there was any
confusion about verification of permissions problem on Windows
and I haven't looked to verify the whole patch. 

With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: RFC: Remove contrib entirely
Next
From: Peter Geoghegan
Date:
Subject: Re: Free indexed_tlist memory explicitly within set_plan_refs()