From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
Cc: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: could not stat promote trigger file leads to shutdown |
Date: | 2019-11-15 18:23:42 |
Message-ID: | 9842.1573842222@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2019-11-15 18:41:06 | Re: Role membership and DROP |
Previous Message | Tom Lane | 2019-11-15 17:48:18 | Re: [PATCH] Implement INSERT SET syntax |