On 2019-11-15 19:23, Tom Lane wrote:
Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes:Say you want to set up promote_trigger_file to point to a file outside of the data directory, maybe because you want to integrate it with some external tooling. So you go into your configuration and set promote_trigger_file = '/srv/foobar/trigger' and reload the server. Everything is happy. The fact that the directory /srv/foobar/ does not exist at this point is completely ignored. Now you become root and run mkdir /srv/foobar and, depending circumstances such as root's umask or the permissions of /srv, your PostgreSQL server crashes immediately. That can't be good.No, it's not good, but the proposed fix of s/ERROR/LOG/ simply delays the problem till later, ie when you try to promote the server nothing happens. That's not good either. (To be clear: I'm not necessarily against that change, I just don't think it's a sufficient response.) If we add a GUC-check-hook test, then the problem of misconfiguration is reduced to the previously unsolved problem that we have crappy feedback for erroneous on-the-fly configuration changes. So it's still unsolved, but at least we've got one unsolved problem not two.
AFAICT, a GUC check hook wouldn't actually be able to address the specific scenario I described. At the time the GUC is set, the containing the directory of the trigger file does not exist yet. This is currently not an error. The problem only happens if after the GUC is set the containing directory appears and is not readable.
I notice that we use LOG level if an SSL key or certificate file is not accessible on reload, so that seems somewhat similar.
We don't have any GUC check hooks on other file system location string settings that ensure accessibility or presence of the file. Although I do notice that we use check_canonical_path() in some places and not others for mysterious and undocumented reasons.
-- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
