public inbox for [email protected]
help / color / mirror / Atom feed[PATCH v2 4/5] Speculative-map WAL segments=0A=
21+ messages / 6 participants
[nested] [flat]
* [PATCH v2 4/5] Speculative-map WAL segments=0A=
@ 2020-03-16 02:14 Takashi Menjo <[email protected]>
0 siblings, 0 replies; 21+ messages in thread
From: Takashi Menjo @ 2020-03-16 02:14 UTC (permalink / raw)
------=_NextPart_000_000D_01D5FE00.9F87CD30
Content-Type: application/octet-stream;
name="v2-0005-Map-WAL-segments-with-MAP_POPULATE-if-non-DAX.patch"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: attachment;
filename="v2-0005-Map-WAL-segments-with-MAP_POPULATE-if-non-DAX.patch"
^ permalink raw reply [nested|flat] 21+ messages in thread
* warn if GUC set to an invalid shared library
@ 2021-12-28 17:45 Justin Pryzby <[email protected]>
0 siblings, 1 reply; 21+ messages in thread
From: Justin Pryzby @ 2021-12-28 17:45 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: Maciek Sakrejda <[email protected]>; Tom Lane <[email protected]>; Bharath Rupireddy <[email protected]>; [email protected]
forking <CA+TgmoawONZqEwe-GqmKERNY1ug0z1QhBzkHdA158xfToHKN9w@mail.gmail.com>
On Mon, Dec 13, 2021 at 09:01:57AM -0500, Robert Haas wrote:
> On Thu, Dec 9, 2021 at 2:32 AM Maciek Sakrejda <[email protected]> wrote:
> > > 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-start
> > situation several times (in development, for what it's worth). The
> > syntax (as Bharath pointed out in the original message) is pretty
> > picky, there are no guard rails, and if you got there through ALTER
> > SYSTEM, you can't fix it with ALTER SYSTEM (because the server isn't
> > up). If you go to fix it manually, you get a scary "Do not edit this
> > file manually!" warning that you have to know to ignore in this case
> > (that's if you find the file after you realize what the fairly generic
> > "FATAL: ... No such file or directory" error in the log is telling
> > you). Plus you have to get the (different!) quoting syntax right or
> > cut your losses and delete the change.
>
> +1. I disagree that trying to detect this kind of problem would be
> "ridiculously over-engineered." I don't know whether it can be done
> elegantly enough that we'd be happy with it and I don't know whether
> it would end up just garden variety over-engineered. But there's
> nothing ridiculous about trying to prevent people from putting their
> system into a state where it won't start.
>
> (To be clear, I also think updating the documentation is sensible,
> without taking a view on exactly what that update should look like.)
Yea, I think documentation won't help to avoid this issue:
If ALTER SYSTEM gives an ERROR, someone will likely to check the docs after a
few minutes if they know that they didn't get the correct syntax.
But if it gives no error nor warning, then most likely they won't know to check
the docs.
We should check session_preload_libraries too, right ? It's PGC_SIGHUP, so if
someone sets the variable and sends sighup, clients will be rejected, and they
had no good opportunity to avoid that.
0001 adds WARNINGs when doing SET:
postgres=# SET local_preload_libraries=xyz;
WARNING: could not load library: xyz: cannot open shared object file: No such file or directory
SET
postgres=# ALTER SYSTEM SET shared_preload_libraries =asdf;
WARNING: could not load library: $libdir/plugins/asdf: cannot open shared object file: No such file or directory
ALTER SYSTEM
0002 adds context when failing to start.
2021-12-27 17:01:12.996 CST postmaster[1403] WARNING: could not load library: $libdir/plugins/asdf: cannot open shared object file: No such file or directory
2021-12-27 17:01:14.938 CST postmaster[1403] FATAL: could not access file "asdf": No such file or directory
2021-12-27 17:01:14.938 CST postmaster[1403] CONTEXT: guc "shared_preload_libraries"
2021-12-27 17:01:14.939 CST postmaster[1403] LOG: database system is shut down
But I wonder whether it'd be adequate context if dlopen were to fail rather
than stat() ?
Before 0003:
2021-12-18 23:13:57.861 CST postmaster[11956] FATAL: could not access file "asdf": No such file or directory
2021-12-18 23:13:57.862 CST postmaster[11956] LOG: database system is shut down
After 0003:
2021-12-18 23:16:05.719 CST postmaster[13481] FATAL: could not load library: asdf: cannot open shared object file: No such file or directory
2021-12-18 23:16:05.720 CST postmaster[13481] LOG: database system is shut down
--
Justin
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2021-12-30 08:20 Bharath Rupireddy <[email protected]>
parent: Justin Pryzby <[email protected]>
0 siblings, 0 replies; 21+ messages in thread
From: Bharath Rupireddy @ 2021-12-30 08:20 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Robert Haas <[email protected]>; Maciek Sakrejda <[email protected]>; Tom Lane <[email protected]>; PostgreSQL Hackers <[email protected]>
On Tue, Dec 28, 2021 at 11:15 PM Justin Pryzby <[email protected]> wrote:
>
> forking <CA+TgmoawONZqEwe-GqmKERNY1ug0z1QhBzkHdA158xfToHKN9w@mail.gmail.com>
>
> On Mon, Dec 13, 2021 at 09:01:57AM -0500, Robert Haas wrote:
> > On Thu, Dec 9, 2021 at 2:32 AM Maciek Sakrejda <[email protected]> wrote:
> > > > 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-start
> > > situation several times (in development, for what it's worth). The
> > > syntax (as Bharath pointed out in the original message) is pretty
> > > picky, there are no guard rails, and if you got there through ALTER
> > > SYSTEM, you can't fix it with ALTER SYSTEM (because the server isn't
> > > up). If you go to fix it manually, you get a scary "Do not edit this
> > > file manually!" warning that you have to know to ignore in this case
> > > (that's if you find the file after you realize what the fairly generic
> > > "FATAL: ... No such file or directory" error in the log is telling
> > > you). Plus you have to get the (different!) quoting syntax right or
> > > cut your losses and delete the change.
> >
> > +1. I disagree that trying to detect this kind of problem would be
> > "ridiculously over-engineered." I don't know whether it can be done
> > elegantly enough that we'd be happy with it and I don't know whether
> > it would end up just garden variety over-engineered. But there's
> > nothing ridiculous about trying to prevent people from putting their
> > system into a state where it won't start.
> >
> > (To be clear, I also think updating the documentation is sensible,
> > without taking a view on exactly what that update should look like.)
>
> Yea, I think documentation won't help to avoid this issue:
>
> If ALTER SYSTEM gives an ERROR, someone will likely to check the docs after a
> few minutes if they know that they didn't get the correct syntax.
> But if it gives no error nor warning, then most likely they won't know to check
> the docs.
>
> We should check session_preload_libraries too, right ? It's PGC_SIGHUP, so if
> someone sets the variable and sends sighup, clients will be rejected, and they
> had no good opportunity to avoid that.
>
> 0001 adds WARNINGs when doing SET:
>
> postgres=# SET local_preload_libraries=xyz;
> WARNING: could not load library: xyz: cannot open shared object file: No such file or directory
> SET
>
> postgres=# ALTER SYSTEM SET shared_preload_libraries =asdf;
> WARNING: could not load library: $libdir/plugins/asdf: cannot open shared object file: No such file or directory
> ALTER SYSTEM
>
> 0002 adds context when failing to start.
>
> 2021-12-27 17:01:12.996 CST postmaster[1403] WARNING: could not load library: $libdir/plugins/asdf: cannot open shared object file: No such file or directory
> 2021-12-27 17:01:14.938 CST postmaster[1403] FATAL: could not access file "asdf": No such file or directory
> 2021-12-27 17:01:14.938 CST postmaster[1403] CONTEXT: guc "shared_preload_libraries"
> 2021-12-27 17:01:14.939 CST postmaster[1403] LOG: database system is shut down
>
> But I wonder whether it'd be adequate context if dlopen were to fail rather
> than stat() ?
>
> Before 0003:
> 2021-12-18 23:13:57.861 CST postmaster[11956] FATAL: could not access file "asdf": No such file or directory
> 2021-12-18 23:13:57.862 CST postmaster[11956] LOG: database system is shut down
>
> After 0003:
> 2021-12-18 23:16:05.719 CST postmaster[13481] FATAL: could not load library: asdf: cannot open shared object file: No such file or directory
> 2021-12-18 23:16:05.720 CST postmaster[13481] LOG: database system is shut down
Overall the idea looks good to me. A warning on ALTER SYSTEM SET seems
reasonable than nothing. ERROR isn't the way to go as it limits the
users of setting the extensions in shared_preload_libraries first,
installing them later. Is NOTICE here a better idea than WARNING?
I haven't looked at the patches though.
Regards,
Bharath Rupireddy.
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-03-23 19:02 Tom Lane <[email protected]>
1 sibling, 1 reply; 21+ messages in thread
From: Tom Lane @ 2022-03-23 19:02 UTC (permalink / raw)
To: Maciek Sakrejda <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; PostgreSQL Hackers <[email protected]>
Maciek Sakrejda <[email protected]> writes:
> In v4, the message looks fine to me for shared_preload_libraries
> (except there is a doubled "is"). However, I also get the message for
> a simple SET with local_preload_libraries:
> postgres=# set local_preload_libraries=xyz;
> WARNING: could not access file "xyz"
> HINT: The server will fail to start with the existing configuration.
> If it is is shut down, it will be necessary to manually edit the
> postgresql.auto.conf file to allow it to start.
> SET
I agree with Maciek's concerns about these HINTs being emitted
inappropriately, but I also have a stylistic gripe: they're only
halfway hints. Given that we fix things so they only print when they
should, the complaint about the server not starting is not a hint,
it's a fact, which per style guidelines means it should be errdetail.
So I think this ought to look more like
WARNING: could not access file "xyz"
DETAIL: The server will fail to start with this setting.
HINT: If the server is shut down, it will be necessary to manually edit the
postgresql.auto.conf file to allow it to start again.
I adjusted the wording a bit too --- YMMV, but I think my text is clearer.
regards, tom lane
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-06-16 03:14 Michael Paquier <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 21+ messages in thread
From: Michael Paquier @ 2022-06-16 03:14 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Maciek Sakrejda <[email protected]>; Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; PostgreSQL Hackers <[email protected]>
On Wed, Mar 23, 2022 at 03:02:23PM -0400, Tom Lane wrote:
> I agree with Maciek's concerns about these HINTs being emitted
> inappropriately, but I also have a stylistic gripe: they're only
> halfway hints. Given that we fix things so they only print when they
> should, the complaint about the server not starting is not a hint,
> it's a fact, which per style guidelines means it should be errdetail.
> So I think this ought to look more like
>
> WARNING: could not access file "xyz"
> DETAIL: The server will fail to start with this setting.
> HINT: If the server is shut down, it will be necessary to manually edit the
> postgresql.auto.conf file to allow it to start again.
>
> I adjusted the wording a bit too --- YMMV, but I think my text is clearer.
It seems to me that there is no objection to the proposed patch, but
an update is required. Justin?
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-06-16 03:50 Justin Pryzby <[email protected]>
parent: Michael Paquier <[email protected]>
0 siblings, 0 replies; 21+ messages in thread
From: Justin Pryzby @ 2022-06-16 03:50 UTC (permalink / raw)
To: Michael Paquier <[email protected]>; +Cc: Tom Lane <[email protected]>; Maciek Sakrejda <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; [email protected]
I've started to think that we should really WARN whenever a (set of) GUC is set
in a manner that the server will fail to start - not just for shared libraries.
In particular, I think the server should also warn if it's going to fail to
start like this:
2022-06-15 22:48:34.279 CDT postmaster[20782] FATAL: WAL streaming (max_wal_senders > 0) requires wal_level "replica" or "logical"
--
Justin
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-07-22 01:54 Justin Pryzby <[email protected]>
1 sibling, 1 reply; 21+ messages in thread
From: Justin Pryzby @ 2022-07-22 01:54 UTC (permalink / raw)
To: Maciek Sakrejda <[email protected]>; +Cc: Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Tom Lane <[email protected]>; Bharath Rupireddy <[email protected]>; [email protected]
Finally returning to this .. rebased and updated per feedback.
I'm not sure of a good place to put test cases for this..
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-07-22 17:42 Maciek Sakrejda <[email protected]>
parent: Justin Pryzby <[email protected]>
0 siblings, 1 reply; 21+ messages in thread
From: Maciek Sakrejda @ 2022-07-22 17:42 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Tom Lane <[email protected]>; Bharath Rupireddy <[email protected]>; PostgreSQL Hackers <[email protected]>
Thanks for picking this back up, Justin.
>I've started to think that we should really WARN whenever a (set of) GUC is set
>in a manner that the server will fail to start - not just for shared libraries.
+0.5. I think it's a reasonable change, but I've never broken my
server with anything other than shared_preload_libraries, so I'd
rather see an improvement here first rather than expanding scope. I
think shared_preload_libraries (and friends) is especially tricky due
to the syntax, and more likely to lead to problems.
On the update patch itself, I have some minor feedback about message wording
postgres=# set local_preload_libraries=xyz;
SET
Great, it's nice that this no longer gives a warning.
postgres=# alter role bob set local_preload_libraries = xyz;
WARNING: could not access file "xyz"
DETAIL: New sessions will currently fail to connect with the new setting.
ALTER ROLE
The warning makes sense, but the detail feels a little awkward. I
think "currently" is sort of redundant with "new setting". And it
could be clearer that the setting did in fact take effect (I know the
ALTER ROLE command tag echo tells you that, but we could reinforce
that in the warning).
Also, I know I said last time that the scope of the warning is clear
from the setting, but looking at it again, I think we could do better.
I guess because when we're generating the error, we don't know whether
the source was ALTER DATABASE or ALTER ROLE, we can't give a more
specific message? Ideally, I think the DETAIL would be something like
"New sessions for this role will fail to connect due to this setting".
Maybe even with a HINT of "Run ALTER ROLE again with a valid value to
fix this"? If that's not feasible, maybe "New sessions for this role
or database will fail to connect due to this setting"? That message is
not as clear about the impact of the change as it could be, but
hopefully you know what command you just ran, so that should make it
unambiguous. I do think without qualifying that, it suggests that all
new sessions are affected.
Hmm, or maybe just "New sessions affected by this setting will fail to
connect"? That also makes the scope clear without the warning having
to be aware of the scope: if you just ran ALTER DATABASE it's pretty
clear that what is affected by the setting is the database. I think
this is probably the way to go, but leaving my thought process above
for context.
postgres=# alter system set shared_preload_libraries = lol;
WARNING: could not access file "$libdir/plugins/lol"
DETAIL: The server will currently fail to start with this setting.
HINT: If the server is shut down, it will be necessary to manually
edit the postgresql.auto.conf file to allow it to start again.
ALTER SYSTEM
I think this works. Tom's copy edit above omitted "currently" from the
DETAIL and did not include the "$libdir/plugins/" prefix. I don't feel
strongly about these either way.
2022-07-22 10:37:50.217 PDT [1131187] LOG: database system is shut down
2022-07-22 10:37:50.306 PDT [1134058] WARNING: could not access file
"$libdir/plugins/lol"
2022-07-22 10:37:50.306 PDT [1134058] DETAIL: The server will
currently fail to start with this setting.
2022-07-22 10:37:50.306 PDT [1134058] HINT: If the server is shut
down, it will be necessary to manually edit the postgresql.auto.conf
file to allow it to start again.
2022-07-22 10:37:50.312 PDT [1134058] FATAL: could not access file
"lol": No such file or directory
2022-07-22 10:37:50.312 PDT [1134058] CONTEXT: while loading shared
libraries for setting "shared_preload_libraries"
from /home/maciek/code/aux/postgres/tmpdb/postgresql.auto.conf:3
2022-07-22 10:37:50.312 PDT [1134058] LOG: database system is shut down
Hmm, I guess this is a side effect of where these messages are
emitted, but at this point, lines 4-6 here are a little confusing, no?
The server was already shut down, and we're trying to start it back
up. If there's no reasonable way to avoid that output, I think it's
okay, but it'd be better to skip it (or adjust it to the new context).
Thanks,
Maciek
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-07-22 17:53 Tom Lane <[email protected]>
parent: Maciek Sakrejda <[email protected]>
0 siblings, 1 reply; 21+ messages in thread
From: Tom Lane @ 2022-07-22 17:53 UTC (permalink / raw)
To: Maciek Sakrejda <[email protected]>; +Cc: Justin Pryzby <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; PostgreSQL Hackers <[email protected]>
Maciek Sakrejda <[email protected]> writes:
>> I've started to think that we should really WARN whenever a (set of) GUC is set
>> in a manner that the server will fail to start - not just for shared libraries.
> +0.5. I think it's a reasonable change, but I've never broken my
> server with anything other than shared_preload_libraries, so I'd
> rather see an improvement here first rather than expanding scope.
Generally speaking, anything that tries to check a combination of
GUC settings is going to be so fragile as to be worthless. We've
learned that lesson the hard way in the past.
> 2022-07-22 10:37:50.217 PDT [1131187] LOG: database system is shut down
> 2022-07-22 10:37:50.306 PDT [1134058] WARNING: could not access file
> "$libdir/plugins/lol"
> 2022-07-22 10:37:50.306 PDT [1134058] DETAIL: The server will
> currently fail to start with this setting.
> 2022-07-22 10:37:50.306 PDT [1134058] HINT: If the server is shut
> down, it will be necessary to manually edit the postgresql.auto.conf
> file to allow it to start again.
> 2022-07-22 10:37:50.312 PDT [1134058] FATAL: could not access file
> "lol": No such file or directory
> 2022-07-22 10:37:50.312 PDT [1134058] CONTEXT: while loading shared
> libraries for setting "shared_preload_libraries"
> from /home/maciek/code/aux/postgres/tmpdb/postgresql.auto.conf:3
> 2022-07-22 10:37:50.312 PDT [1134058] LOG: database system is shut down
> Hmm, I guess this is a side effect of where these messages are
> emitted, but at this point, lines 4-6 here are a little confusing, no?
This indicates that the warning is being issued in the wrong place.
It's okay if it comes out during ALTER SYSTEM. It's not okay if it
comes out during server start; then it's just an annoyance.
regards, tom lane
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-07-22 18:35 Justin Pryzby <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 21+ messages in thread
From: Justin Pryzby @ 2022-07-22 18:35 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Maciek Sakrejda <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; [email protected]
On Fri, Jul 22, 2022 at 01:53:21PM -0400, Tom Lane wrote:
> > 2022-07-22 10:37:50.217 PDT [1131187] LOG: database system is shut down
> > 2022-07-22 10:37:50.306 PDT [1134058] WARNING: could not access file "$libdir/plugins/lol"
> > 2022-07-22 10:37:50.306 PDT [1134058] DETAIL: The server will currently fail to start with this setting.
> > 2022-07-22 10:37:50.306 PDT [1134058] HINT: If the server is shut down, it will be necessary to manually edit the postgresql.auto.conf file to allow it to start again.
> > 2022-07-22 10:37:50.312 PDT [1134058] FATAL: could not access file "lol": No such file or directory
> > 2022-07-22 10:37:50.312 PDT [1134058] CONTEXT: while loading shared libraries for setting "shared_preload_libraries" from /home/maciek/code/aux/postgres/tmpdb/postgresql.auto.conf:3
> > 2022-07-22 10:37:50.312 PDT [1134058] LOG: database system is shut down
>
> > Hmm, I guess this is a side effect of where these messages are
> > emitted, but at this point, lines 4-6 here are a little confusing, no?
>
> This indicates that the warning is being issued in the wrong place.
> It's okay if it comes out during ALTER SYSTEM. It's not okay if it
> comes out during server start; then it's just an annoyance.
This was a regression from the previous patch version, and I even noticed the
problem, but then forgot when returning to the patch :(
The previous patch version checked if (!IsUnderPostmaster()) before warning.
Is there a better way ?
ALTER SYSTEM uses PGC_S_FILE, the same as during startup..
--
Justin
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-07-22 19:00 Tom Lane <[email protected]>
parent: Justin Pryzby <[email protected]>
0 siblings, 1 reply; 21+ messages in thread
From: Tom Lane @ 2022-07-22 19:00 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Maciek Sakrejda <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; [email protected]
Justin Pryzby <[email protected]> writes:
> On Fri, Jul 22, 2022 at 01:53:21PM -0400, Tom Lane wrote:
>> This indicates that the warning is being issued in the wrong place.
>> It's okay if it comes out during ALTER SYSTEM. It's not okay if it
>> comes out during server start; then it's just an annoyance.
> The previous patch version checked if (!IsUnderPostmaster()) before warning.
> Is there a better way ?
> ALTER SYSTEM uses PGC_S_FILE, the same as during startup..
Shouldn't you be doing this when the source is PGC_S_TEST, instead?
That's pretty much what it's for. See check_default_table_access_method
and other examples.
regards, tom lane
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-07-22 19:14 Justin Pryzby <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 1 reply; 21+ messages in thread
From: Justin Pryzby @ 2022-07-22 19:14 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Maciek Sakrejda <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; [email protected]
On Fri, Jul 22, 2022 at 03:00:23PM -0400, Tom Lane wrote:
> Justin Pryzby <[email protected]> writes:
> > On Fri, Jul 22, 2022 at 01:53:21PM -0400, Tom Lane wrote:
> >> This indicates that the warning is being issued in the wrong place.
> >> It's okay if it comes out during ALTER SYSTEM. It's not okay if it
> >> comes out during server start; then it's just an annoyance.
>
> > The previous patch version checked if (!IsUnderPostmaster()) before warning.
> > Is there a better way ?
>
> > ALTER SYSTEM uses PGC_S_FILE, the same as during startup..
>
> Shouldn't you be doing this when the source is PGC_S_TEST, instead?
> That's pretty much what it's for. See check_default_table_access_method
> and other examples.
That makes sense, but it doesn't work for ALTER SYSTEM, which uses PGC_S_FILE.
postgres=# ALTER SYSTEM SET shared_preload_libraries =a;
2022-07-22 14:07:25.489 CDT client backend[23623] psql WARNING: source 3
WARNING: source 3
2022-07-22 14:07:25.489 CDT client backend[23623] psql WARNING: could not access file "$libdir/plugins/a"
2022-07-22 14:07:25.489 CDT client backend[23623] psql DETAIL: The server will currently fail to start with this setting.
2022-07-22 14:07:25.489 CDT client backend[23623] psql HINT: If the server is shut down, it will be necessary to manually edit the postgresql.auto.conf file to allow it to start again.
postgres=# ALTER SYSTEM SET default_table_access_method=abc;
Breakpoint 1, check_default_table_access_method (newval=0x7ffe4c6fe820, extra=0x7ffe4c6fe828, source=PGC_S_FILE) at tableamapi.c:112
--
Justin
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-07-22 19:26 Tom Lane <[email protected]>
parent: Justin Pryzby <[email protected]>
0 siblings, 1 reply; 21+ messages in thread
From: Tom Lane @ 2022-07-22 19:26 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Maciek Sakrejda <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; [email protected]
Justin Pryzby <[email protected]> writes:
> On Fri, Jul 22, 2022 at 03:00:23PM -0400, Tom Lane wrote:
>> Shouldn't you be doing this when the source is PGC_S_TEST, instead?
> That makes sense, but it doesn't work for ALTER SYSTEM, which uses PGC_S_FILE.
Hmph. I wonder if we shouldn't change that, because it's a lie.
The value isn't actually coming from the config file, at least
not yet.
We might need to invent a separate PGC_S_TEST_FILE value; or maybe it'd
be better to pass the "this is a test" flag separately? But that'd
require changing the signature of all GUC check hooks, so probably
it's unduly invasive. I'm not sure whether any users of the TEST
capability need to distinguish values proposed for postgresql.auto.conf
from those proposed for pg_db_role_setting ... but I guess it's
plausible that somebody might.
regards, tom lane
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-09-02 22:24 Justin Pryzby <[email protected]>
parent: Tom Lane <[email protected]>
0 siblings, 2 replies; 21+ messages in thread
From: Justin Pryzby @ 2022-09-02 22:24 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Maciek Sakrejda <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; Cary Huang <[email protected]>; [email protected]
On Fri, Jul 22, 2022 at 03:26:47PM -0400, Tom Lane wrote:
> Justin Pryzby <[email protected]> writes:
> > On Fri, Jul 22, 2022 at 03:00:23PM -0400, Tom Lane wrote:
> >> Shouldn't you be doing this when the source is PGC_S_TEST, instead?
>
> > That makes sense, but it doesn't work for ALTER SYSTEM, which uses PGC_S_FILE.
>
> Hmph. I wonder if we shouldn't change that, because it's a lie.
I think so, and I was going to raise this question some months ago when
I first picked up the patch.
The question is, which behavior do we want ?
postgres=# ALTER SYSTEM SET default_table_access_method=abc;
2022-07-22 15:24:55.445 CDT client backend[27938] psql ERROR: invalid value for parameter "default_table_access_method": "abc"
2022-07-22 15:24:55.445 CDT client backend[27938] psql DETAIL: Table access method "abc" does not exist.
2022-07-22 15:24:55.445 CDT client backend[27938] psql STATEMENT: ALTER SYSTEM SET default_table_access_method=abc;
That behavior differs from ALTER SYSTEM SET shared_preload_libraries,
which supports first seting the GUC and then installing the library. If
that wasn't supported, I think we'd just throw an error and avoid the
possibility that the server can't start.
It caused no issue when I changed:
/* Check that it's acceptable for the indicated parameter */
if (!parse_and_validate_value(record, name, value,
- PGC_S_FILE, ERROR,
+ PGC_S_TEST, ERROR,
&newval, &newextra))
I'm not sure where to go from here.
--
Justin
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-10-12 05:34 Michael Paquier <[email protected]>
parent: Justin Pryzby <[email protected]>
1 sibling, 0 replies; 21+ messages in thread
From: Michael Paquier @ 2022-10-12 05:34 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Tom Lane <[email protected]>; Maciek Sakrejda <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; Cary Huang <[email protected]>; [email protected]
On Fri, Sep 02, 2022 at 05:24:58PM -0500, Justin Pryzby wrote:
> I'm not sure where to go from here.
Not sure either, but the thread has no activity for a bit more than 1
month, so marked as RwF for now.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../../[email protected]/2-signature.asc)
download
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-10-29 17:40 Justin Pryzby <[email protected]>
parent: Justin Pryzby <[email protected]>
1 sibling, 1 reply; 21+ messages in thread
From: Justin Pryzby @ 2022-10-29 17:40 UTC (permalink / raw)
To: Tom Lane <[email protected]>; +Cc: Maciek Sakrejda <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; Cary Huang <[email protected]>; [email protected]
On Fri, Sep 02, 2022 at 05:24:58PM -0500, Justin Pryzby wrote:
> It caused no issue when I changed:
>
> /* Check that it's acceptable for the indicated parameter */
> if (!parse_and_validate_value(record, name, value,
> - PGC_S_FILE, ERROR,
> + PGC_S_TEST, ERROR,
> &newval, &newextra))
>
> I'm not sure where to go from here.
I'm hoping for some guidance ; this simple change may be naive, but I'm not
sure what a wider change would look like.
--
Justin
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-10-30 23:12 Maciek Sakrejda <[email protected]>
parent: Justin Pryzby <[email protected]>
0 siblings, 1 reply; 21+ messages in thread
From: Maciek Sakrejda @ 2022-10-30 23:12 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Tom Lane <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; Cary Huang <[email protected]>; [email protected]
On Sat, Oct 29, 2022 at 10:40 AM Justin Pryzby <[email protected]> wrote:
>
> On Fri, Sep 02, 2022 at 05:24:58PM -0500, Justin Pryzby wrote:
> > It caused no issue when I changed:
> >
> > /* Check that it's acceptable for the indicated parameter */
> > if (!parse_and_validate_value(record, name, value,
> > - PGC_S_FILE, ERROR,
> > + PGC_S_TEST, ERROR,
> > &newval, &newextra))
> >
> > I'm not sure where to go from here.
>
> I'm hoping for some guidance ; this simple change may be naive, but I'm not
> sure what a wider change would look like.
I assume you mean guidance on implementation details here, and not on
design. I still think this is a useful patch and I'd be happy to
review and try out future iterations, but I don't have any useful
input here.
Also, for what it's worth, I think requiring the libraries to be in
place before running ALTER SYSTEM does not really seem that onerous. I
can't really think of use cases it precludes.
Thanks,
Maciek
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-10-31 13:31 Justin Pryzby <[email protected]>
parent: Maciek Sakrejda <[email protected]>
0 siblings, 2 replies; 21+ messages in thread
From: Justin Pryzby @ 2022-10-31 13:31 UTC (permalink / raw)
To: Maciek Sakrejda <[email protected]>; +Cc: Tom Lane <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; Cary Huang <[email protected]>; [email protected]
On Sun, Oct 30, 2022 at 04:12:33PM -0700, Maciek Sakrejda wrote:
> On Sat, Oct 29, 2022 at 10:40 AM Justin Pryzby <[email protected]> wrote:
> >
> > On Fri, Sep 02, 2022 at 05:24:58PM -0500, Justin Pryzby wrote:
> > > It caused no issue when I changed:
> > >
> > > /* Check that it's acceptable for the indicated parameter */
> > > if (!parse_and_validate_value(record, name, value,
> > > - PGC_S_FILE, ERROR,
> > > + PGC_S_TEST, ERROR,
> > > &newval, &newextra))
> > >
> > > I'm not sure where to go from here.
> >
> > I'm hoping for some guidance ; this simple change may be naive, but I'm not
> > sure what a wider change would look like.
>
> I assume you mean guidance on implementation details here, and not on
ALTER SYSTEM tests the new/proposed setting using PGC_S_FILE ("which is
a lie").
It seems better to address that lie before attempting to change the
behavior of *_preload_libraries.
PGC_S_TEST is a better fit, so my question is whether it's really that
simple ?
> Also, for what it's worth, I think requiring the libraries to be in
> place before running ALTER SYSTEM does not really seem that onerous. I
> can't really think of use cases it precludes.
Right now, it's allowed to set the GUC before installing the shlib.
That's a supported case (see the 11 month old messages toward the
beginning of this thread).
--
Justin
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-10-31 13:43 Tom Lane <[email protected]>
parent: Justin Pryzby <[email protected]>
1 sibling, 0 replies; 21+ messages in thread
From: Tom Lane @ 2022-10-31 13:43 UTC (permalink / raw)
To: Justin Pryzby <[email protected]>; +Cc: Maciek Sakrejda <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; Cary Huang <[email protected]>; [email protected]
Justin Pryzby <[email protected]> writes:
> On Sun, Oct 30, 2022 at 04:12:33PM -0700, Maciek Sakrejda wrote:
>> Also, for what it's worth, I think requiring the libraries to be in
>> place before running ALTER SYSTEM does not really seem that onerous. I
>> can't really think of use cases it precludes.
> Right now, it's allowed to set the GUC before installing the shlib.
> That's a supported case (see the 11 month old messages toward the
> beginning of this thread).
Yeah, I am afraid that you will break assorted dump/restore and
pg_upgrade scenarios if you insist on that.
regards, tom lane
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2022-11-01 22:26 Justin Pryzby <[email protected]>
parent: Justin Pryzby <[email protected]>
1 sibling, 1 reply; 21+ messages in thread
From: Justin Pryzby @ 2022-11-01 22:26 UTC (permalink / raw)
To: Maciek Sakrejda <[email protected]>; +Cc: Tom Lane <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; Cary Huang <[email protected]>; [email protected]
On Mon, Oct 31, 2022 at 08:31:20AM -0500, Justin Pryzby wrote:
> On Sun, Oct 30, 2022 at 04:12:33PM -0700, Maciek Sakrejda wrote:
> > On Sat, Oct 29, 2022 at 10:40 AM Justin Pryzby <[email protected]> wrote:
> > > On Fri, Sep 02, 2022 at 05:24:58PM -0500, Justin Pryzby wrote:
> > > > It caused no issue when I changed:
> > > >
> > > > /* Check that it's acceptable for the indicated parameter */
> > > > if (!parse_and_validate_value(record, name, value,
> > > > - PGC_S_FILE, ERROR,
> > > > + PGC_S_TEST, ERROR,
> > > > &newval, &newextra))
> > > >
> > > > I'm not sure where to go from here.
> > >
> > > I'm hoping for some guidance ; this simple change may be naive, but I'm not
> > > sure what a wider change would look like.
> >
> > I assume you mean guidance on implementation details here, and not on
>
> ALTER SYSTEM tests the new/proposed setting using PGC_S_FILE ("which is
> a lie").
>
> It seems better to address that lie before attempting to change the
> behavior of *_preload_libraries.
>
> PGC_S_TEST is a better fit, so my question is whether it's really that
> simple ?
I've added the trivial change as 0001 and re-opened the patch (which ended
up in January's CF)
If for some reason it's not really as simple as that, then 001 will
serve as a "straw-man patch" hoping to elicit discussion on that point.
--
Justin
^ permalink raw reply [nested|flat] 21+ messages in thread
* Re: warn if GUC set to an invalid shared library
@ 2024-01-07 13:27 Justin Pryzby <[email protected]>
parent: Justin Pryzby <[email protected]>
0 siblings, 0 replies; 21+ messages in thread
From: Justin Pryzby @ 2024-01-07 13:27 UTC (permalink / raw)
To: [email protected]; +Cc: Tom Lane <[email protected]>; Robert Haas <[email protected]>; David G. Johnston <[email protected]>; Bharath Rupireddy <[email protected]>; Cary Huang <[email protected]>; Maciek Sakrejda <[email protected]>; Shubham Khanna <[email protected]>
On Fri, Jul 22, 2022 at 03:26:47PM -0400, Tom Lane wrote:
> Hmph. I wonder if we shouldn't change that, because it's a lie.
> The value isn't actually coming from the config file, at least
> not yet.
On Thu, Jul 06, 2023 at 03:15:20PM -0500, Justin Pryzby wrote:
> On Sat, Oct 29, 2022 at 10:40 AM Justin Pryzby <[email protected]> wrote:
> > > > > On Fri, Sep 02, 2022 at 05:24:58PM -0500, Justin Pryzby wrote:
> > > > > > It caused no issue when I changed:
> > > > > >
> > > > > > /* Check that it's acceptable for the indicated parameter */
> > > > > > if (!parse_and_validate_value(record, name, value,
> > > > > > - PGC_S_FILE, ERROR,
> > > > > > + PGC_S_TEST, ERROR,
> > > > > > &newval, &newextra))
> > > > > >
> > > > > > I'm not sure where to go from here.
> > > > >
> > > > > I'm hoping for some guidance ; this simple change may be naive, but I'm not
> > > > > sure what a wider change would look like.
>
> I'm still hoping.
@cfbot: rebased
^ permalink raw reply [nested|flat] 21+ messages in thread
end of thread, other threads:[~2024-01-07 13:27 UTC | newest]
Thread overview: 21+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-03-16 02:14 [PATCH v2 4/5] Speculative-map WAL segments=0A= Takashi Menjo <[email protected]>
2021-12-28 17:45 warn if GUC set to an invalid shared library Justin Pryzby <[email protected]>
2021-12-30 08:20 ` Re: warn if GUC set to an invalid shared library Bharath Rupireddy <[email protected]>
2022-03-23 19:02 ` Re: warn if GUC set to an invalid shared library Tom Lane <[email protected]>
2022-06-16 03:14 ` Re: warn if GUC set to an invalid shared library Michael Paquier <[email protected]>
2022-06-16 03:50 ` Re: warn if GUC set to an invalid shared library Justin Pryzby <[email protected]>
2022-07-22 01:54 ` Re: warn if GUC set to an invalid shared library Justin Pryzby <[email protected]>
2022-07-22 17:42 ` Re: warn if GUC set to an invalid shared library Maciek Sakrejda <[email protected]>
2022-07-22 17:53 ` Re: warn if GUC set to an invalid shared library Tom Lane <[email protected]>
2022-07-22 18:35 ` Re: warn if GUC set to an invalid shared library Justin Pryzby <[email protected]>
2022-07-22 19:00 ` Re: warn if GUC set to an invalid shared library Tom Lane <[email protected]>
2022-07-22 19:14 ` Re: warn if GUC set to an invalid shared library Justin Pryzby <[email protected]>
2022-07-22 19:26 ` Re: warn if GUC set to an invalid shared library Tom Lane <[email protected]>
2022-09-02 22:24 ` Re: warn if GUC set to an invalid shared library Justin Pryzby <[email protected]>
2022-10-12 05:34 ` Re: warn if GUC set to an invalid shared library Michael Paquier <[email protected]>
2022-10-29 17:40 ` Re: warn if GUC set to an invalid shared library Justin Pryzby <[email protected]>
2022-10-30 23:12 ` Re: warn if GUC set to an invalid shared library Maciek Sakrejda <[email protected]>
2022-10-31 13:31 ` Re: warn if GUC set to an invalid shared library Justin Pryzby <[email protected]>
2022-10-31 13:43 ` Re: warn if GUC set to an invalid shared library Tom Lane <[email protected]>
2022-11-01 22:26 ` Re: warn if GUC set to an invalid shared library Justin Pryzby <[email protected]>
2024-01-07 13:27 ` Re: warn if GUC set to an invalid shared library Justin Pryzby <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox