RE: [EXTERNAL] Re: should we document an example to set multiple libraries in shared_preload_libraries?

On Wed, Dec 1, 2021 at 5:15 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Justin Pryzby <pryzby@telsasoft.com> writes:
> > +1 to document it, but it seems like the worse problem is allowing 
> > +the admin to
> > write a configuration which causes the server to fail to start, 
> > without having issued a warning.
>
> > I think you could fix that with a GUC check hook to emit a warning.
> > ...
>
> Considering the vanishingly small number of actual complaints we've 
> seen about this, that sounds ridiculously over-engineered.
> A documentation example should be sufficient.

>I don't know if this will tip the scales, but I'd like to lodge a belated complaint. I've gotten myself in this
server-fails-to-startsituation several times (in development, for what it's worth). The syntax (as Bharath pointed out
inthe original message) is pretty picky, there are no guard rails, and if you got there through ALTER SYSTEM, you can't
fixit with ALTER SYSTEM (because the server isn't up). If you go to fix it manually, you get a scary "Do not edit this
filemanually!" warning that you have to know to ignore in this case (that's if you find the file after you realize what
thefairly generic
 
>"FATAL: ... No such file or directory" error in the log is telling you). Plus you have to get the (different!) quoting
syntaxright or cut your losses and delete the change.
 
>
>I'm over-dramatizing this a bit, but I do think there are a lot of opportunities to make mistakes here, and this
behaviorcould be more user-friendly beyond just documentation changes. If a config change is bogus most likely due to a
quotingmistake or a typo, a warning would be fantastic (i.e., the stat() check Justin suggested). Or maybe the FATAL
logmessage on a failed startup could include the source of the problem?
 
>
>Thanks,
>Maciek

I may have missed something in this stream, but is this a system controlled by Patroni? In any case I to have gotten
stucklike this. If this is a Patroni system, I've discovered that patroni either ides or prevents "out of memory"
messagesfrom getting into the db log. If it is patroni controlled, I've solved this by turning off Patroni, starting
theDB using pg_ctl and then I can examine the log messages. With pg_ctl, you can edit the postgresql.conf and see what
youcan do. Alternatively, with the DCS you can make 'dynamic edits' to the system configuration without the db running.
Usethe patroni control utility to do an 'edit-config' to make the changes. Then reload the config (same utility) and
thenyou can bring up the db with Patroni...
 

Smiles,
phil