On 3/15/17 3:00 AM, Tsunakawa, Takayuki wrote:
> From: pgsql-hackers-ow...@postgresql.org
>> [mailto:pgsql-hackers-ow...@postgresql.org] On Behalf Of David Steele
>>> But it might be worth thinking about whether we want to encourage
>>> people to do manual chmod's at all; that's fairly easy to get wrong,
>>> particularly given the difference in X bits that should be applied to
>>> files and directories.  Another approach that could be worth
>>> considering is a PGC_POSTMASTER GUC with just two states (group access
>>> or not) and make it the postmaster's responsibility to do the
>>> equivalent of chmod -R to make the file tree match the GUC.  I think
>>> we do a tree scan anyway for other purposes, so correcting any wrong
>>> file permissions might not be much added work in the normal case.
>> The majority of scanning is done in recovery (to find and remove unlogged
>> tables) and I'm not sure we would want to add that overhead to normal 
>> startup.
> I'm on David's side, too.  I don't postmaster to always scan all files at 
> startup.
> On the other hand, just doing "chmod -R $PGDATA" is not enough, because chmod 
> doesn't follow the symbolic links.  Symbolic links are used for pg_tblspc/* 
> and pg_wal at least.  FYI, MySQL's manual describes the pithole like this:

Good point - I think we'll need to add that to the docs as well.

> I think we also need to describe the procedure carefully.  That said, it 
> would be best to make users aware of a configuration alternative (group 
> access) with enough documentation when they first build the database or 
> upgrade the database cluster.  Just describing the alternative only in initdb 
> reference page would result in being unaware of the better configuration, 
> like --data-checksum.

I'm working on a new approach incorporating everybody's suggestions and
enhanced documentation.  It should be ready on Monday.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to