On 3/18/17 3:57 PM, Robert Haas wrote:
> On Wed, Mar 15, 2017 at 3:00 AM, Tsunakawa, Takayuki
> <tsunakawa.takay@jp.fujitsu.com> wrote:
>> I'm on David's side, too. I don't postmaster to always scan all files at startup.
>
> +1. Even just doing it during crash recovery, it can take a
> regrettably long time on machines with tons of relations and a very
> slow disk. I've been sort of thinking that we should add some logging
> there so that users know what's happening when that code goes into the
> tank - I've seen that come up 3 or 4 times now, and I'm getting tired
> of telling people to run strace to find out.
Most of this time is spent scanning for unlogged tables. We were
working on a patch to put unlogged tables (except for the init fork) in
a pg_unlogged directory created for each tablespace, just like
pgsql_temp. This would make cleanup a lot faster and make it easier for
backup software to skip relations that can't be restored and only take
up space.
Unfortunately the patch was not ready for the last CF and maybe would
not have been a good candidate anyway due to complexity. It's still on
our radar, though.
> I think Tom's concerns about people doing insecure stuff are
> excessive. People can do insecure stuff no matter what we do, and
> trying to prevent them often leads to them doing even-more-insecure
> stuff. That having been aid, I do wonder whether the idea of allowing
> group read privileges specifically might be a better concept than a
> umask, though, because (1) it's not obvious that there's a real use
> case for anything other than group read privileges, so why not support
> exactly that to avoid user confusion and (2) umask is a pretty
> specific concept that may not apply on every platform. For example,
> AFS has an ACL list instead of using the traditional UNIX permission
> bits, and I'm not sure Windows has the umask concept exactly either.
> So wording what we're trying to do a bit more generically might be
> smart.
We took Tom's advice to heart and this is the direction the patch is
currently going in. Even the GUC may be too much as there are number of
tools that write into PGDATA but don't read postgresql.conf. It looks
like using the permissions of PGDATA may be the best way to go.
In any case, the changes required have enlarged the size and scope of
the patch considerably and we are not confident that it will be done in
time to commit for v10.
I have marked this submission "Returned with Feedback".
--
-David
david@pgmasters.net
