What is the point of this one? SHOW data_directory_mode reports the Unix permission bits on the data directory — 0700 or 0750 — and that is the entire extent of what it does. It’s read-only; you can’t set it. And it reports a fact that ls -ld $PGDATA would tell you just as well. So why is it a GUC?
The honest answer is the same as for block_size and data_checksums: a connected client may have a SQL connection and nothing else — no shell on the box, no filesystem access, possibly not even on the same host. The parameter exists so that something holding only a database connection can ask the server what its own data directory permissions are. That’s it. The GUC is a readout; the interesting part is the thing it’s reading out, which has an actual history worth thirty seconds.
Why there are two values
Through PostgreSQL 10, the data directory permissions were not negotiable. initdb created the directory as 0700 — owner only — and the postmaster refused to start if it found anything else, logging the data directory has group or world access error that has confused everyone who has ever tried to put $PGDATA on an external drive with permissive default mounting. The reasoning was sound: the data directory holds everything, in the clear, and anyone who can read those files can read your database.
PostgreSQL 11 relaxed it, slightly and deliberately. You can now run initdb --allow-group-access (-g), which creates the directory 0750 and files 0640 — owner read-write, group read-only. The postmaster, from 11 on, accepts either 0700 or 0750 and rejects everything else. data_directory_mode is how you find out, over a SQL connection, which of the two you got.
The point of group access is narrow and real: it lets an unprivileged user in the postgres group read the data directory without being able to write it. That’s exactly the privilege a backup process wants — enough to copy every file, not enough to corrupt anything. pg_basebackup, pg_receivewal, and pg_recvlogical all honor the mode and create their output with matching permissions, so a backup operator can run as a minimal-privilege account in the postgres group instead of as the superuser. For a security posture that cares about least privilege on the backup path, that’s a genuine improvement, and it’s the whole reason both the feature and this little readout parameter exist.
One operational note that the value’s read-only-ness obscures: changing group access on an existing cluster isn’t a matter of flipping anything. You shut the server down, chmod every directory and file in the data directory to the new mode, and restart — do it halfway and you get a mix of modes that the tools won’t handle cleanly. The GUC will then report the new value, but the GUC was never the thing you changed.
So: SHOW data_directory_mode answers one question — “does this cluster allow group read access?” — for a client that can’t stat the directory itself. If the answer is 0750, someone enabled group access at initdb time, probably for a backup tool, probably on purpose. If it’s 0700, they didn’t. There is nothing here to tune; there’s just a fact to look up, and now you know what the fact means.