> Let me think about that a bit, and look over your v2 approach; my
> kneejerk reaction was that this is a dangerous situation to be in. I
> want to know that my HBA is invalid when I reload, not later on down
> the line.
Yes, I see that concern, but that's a bit trickier. To do that
properly we have to validate the variables, including their values,
not just their names. If we only validate the names, that doesn't
guarantee anything.
> And it makes sense that the postmaster is not going to somehow unload
> and reload those libraries during SIGHUP, just to check GUC settings.
> Hrmmm...
Would it be a good idea for it to dlopen/dlclose libraries? The
requirements of dlclose are not that strict, I'm not sure if it could
cause any issues. Opening a quick background process to verify it
seems safer, but even then, it could only verify the libraries
mentioned directly in the configuration.
I could write the code that does this for pg_hba on startup/reload,
but the tricky part is that we have to document that properly, to make
sure that the extensions also expects and handles the situation
correctly (that we try to validate gucs for all hba lines). Or start
one background process per hba line...
> I might be misunderstanding, but wouldn't that imply that DBAs could
> now put every existing SIGHUP setting into HBA? That doesn't seem
> good.
Yes, that would mean that. I'm not saying that would be
better/semantically correct, but technically it could also work,
that's why I mentioned it. The main use of PGC_HBA in this patch is to
add additional error reporting / separate what can be placed into
pg_hba. I could argue both for this approach and the opposite where we
allow other variables in pg_hba.
