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

From Abhijit Menon-Sen
Subject Re: fsync-pgdata-on-recovery tries to write to more files than previously
Date
Msg-id 20150527013745.GB30922@toroid.org
Whole thread Raw
In response to Re: fsync-pgdata-on-recovery tries to write to more files than previously  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
At 2015-05-26 22:44:03 +0200, andres@anarazel.de wrote:
>
> So, this was discussed in the following thread, starting at:
> http://archives.postgresql.org/message-id/20150403163232.GA28444%40eldon.alvh.no-ip.org

Sorry, I didn't see this before replying.

> There are no other places we it's "allowed" to introduce symlinks and
> we have refuted bugreports of people having problems after doing that.

OK.

> So what I propose is:
> 1) Remove the automatic symlink following
> 2) Follow pg_tbspc/*, pg_xlog if it's a symlink, fix the latter in
>    initdb -S
> 3) Add a elevel argument to walkdir(), return if AllocateDir() fails,
>    continue for stat() failures in the readdir() loop.
> 4) Add elevel argument to pre_sync_fname, fsync_fname, return after
>    errors.
> 5) Accept EACCESS, ETXTBSY (if defined) when open()ing the files. By
>    virtue of not following symlinks we should not need to worry about
>    EROFS

Makes sense. I've got most of that done, I'll just remove the symlink
following (or rather, restrict it to the cases mentioned), test a bit,
and post.

> I'm inclined to think that 4) is a big enough compat break that a
> fsync_fname_ext with the new argument is a good idea.

Agreed.

-- Abhijit



pgsql-hackers by date:

Previous
From: Abhijit Menon-Sen
Date:
Subject: Re: fsync-pgdata-on-recovery tries to write to more files than previously
Next
From: Stephen Frost
Date:
Subject: Re: [COMMITTERS] pgsql: Row-Level Security Policies (RLS)