From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Justin Pryzby <pryzby(at)telsasoft(dot)com> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Cary Huang <cary(dot)huang(at)highgo(dot)ca>, Maciek Sakrejda <m(dot)sakrejda(at)gmail(dot)com> |
Subject: | Re: warn if GUC set to an invalid shared library |
Date: | 2024-05-24 13:26:54 |
Message-ID: | CA+TgmoY3_=t=dStVXMpYqO0EpPMTEtFi3TaGsvO=g5yY=0bQAw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Jul 6, 2023 at 4:15 PM Justin Pryzby <pryzby(at)telsasoft(dot)com> wrote:
> I'm still hoping.
Hi,
I got asked to take a look at this thread.
First, I want to explain why I think this thread hasn't gotten as much
feedback as Justin was hoping. It is always possible for any thread to
have that problem just because people are busy or not interested.
However, I think in this case an aggravating factor is that the
discussion is very "high context"; it's hard to understand what the
open problems are without reading a lot of emails and understanding
how they all relate to each other. One of the key questions is whether
we should replace PGC_S_FILE with PGC_S_TEST in
AlterSystemSetConfigFile. I originally thought, based on reading one
of the emails, that the question was whether we should do that out of
some sense of intellectual purity, and my answer was "probably not,
because that would change the behavior in a way that doesn't seem
good." But then I realized, reading another email, that Justin already
knew that the behavior would change, or at least I'm 90% certain that
he knows that. So now I think the question is whether we want that
behavior change, but he only provided one example of how the behavior
changes, and it's not clear how many other scenarios are affected or
in what way, so it's still a bit hard to answer. Plus, it took me 10
minutes to figure out what the question was. I think that if the
question had been phrased in a way that was easily understandable to
any experienced PostgreSQL user, it's a lot more likely that one or
more people would have had an opinion on whether it was good or bad.
As it is, I think most people probably didn't understand the question,
and the people who did understand the question may not have wanted to
spend the time to do the research that they would have needed to do to
come up with an intelligent answer. I'm not saying any of this to
criticize Justin or to say that he did anything wrong, but I think we
have lots of examples of stuff like this on the mailing list, where
people are sad because they didn't get an answer, but don't always
realize that there might be things they could do to improve their
chances.
On the behavior change itself, it seems to me that there's a big
difference between shared_preload_libraries=bogus and work_mem=bogus.
The former is valid or invalid according to whether bogus.so exists in
an appropriate directory on the local machine, but the latter is
categorically invalid. I'm not sure to what degree we have the
infrastructure to distinguish those cases, but to the extent that we
do, handling them differently is completely defensible. It's
reasonable to allow the first one on the theory that the
presently-invalid configuration may at a later time become valid, but
that's not reasonable in the second case. So if changing PGC_S_FILE to
PGC_S_TEST in AlterSystemSetConfigFile is going to have the effect of
allowing garbage values into postgresql.auto.conf that would currently
get blocked, I think that's a bad plan and we shouldn't do it. But
it's quite possible I'm not fully understanding the situation.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2024-05-24 13:28:32 | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
Previous Message | Pavel Stehule | 2024-05-24 13:20:53 | Re: Schema variables - new implementation for Postgres 15 |