On 3/15/17 3:00 AM, Tsunakawa, Takayuki wrote:
> From: pgsql-hackers-owner@postgresql.org
>> [mailto:pgsql-hackers-owner@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.
Symboliclinks 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
configurationalternative (group access) with enough documentation when they first build the database or upgrade the
databasecluster. Just describing the alternative only in initdb reference page would result in being unaware of the
betterconfiguration, like --data-checksum.
I'm working on a new approach incorporating everybody's suggestions and
enhanced documentation. It should be ready on Monday.
--
-David
david@pgmasters.net
