Re: could not stat promote trigger file leads to shutdown
От | Peter Eisentraut |
---|---|
Тема | Re: could not stat promote trigger file leads to shutdown |
Дата | |
Msg-id | fa103866-894e-a2bc-067d-0d590d6fb7a0@2ndquadrant.com обсуждение исходный текст |
Ответ на | Re: could not stat promote trigger file leads to shutdown (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: could not stat promote trigger file leads to shutdown
Re: could not stat promote trigger file leads to shutdown |
Список | pgsql-hackers |
On 2019-11-20 16:21, Tom Lane wrote: >> 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. > True, if the hook just consists of trying fopen() and checking the > errno. Would it be feasible to insist that the containing directory > exist and be readable? We have enough infrastructure that that > should only take a few lines of code, so the question is whether > or not that's a nicer behavior than we have now. Is it possible to do this in a mostly bullet-proof way? Just because the directory exists and looks pretty good otherwise, doesn't mean we can read a file created in it later in a way that doesn't fall afoul of the existing error checks. There could be something like SELinux lurking, for example. Maybe some initial checking would be useful, but I think we still need to downgrade the error check at use time a bit to not crash in the cases that we miss. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: