-
-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
db settings: reload on connection recovery, only get them from global/current-database scope and change dash to underscore #1760
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
6b901fe
Correct db settings to use "_" instead of "-"
steve-chavez 9a73faa
Restrict db settings to current db and global
steve-chavez ba54ec1
Reread in-db config when recoverying connection
steve-chavez 980c4cd
Change db-load-guc-config to db-config
steve-chavez File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The term in-database config is much clearer.
Perhaps the
db-load-guc-config
option should be changed toconfig-in-db
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm, I see your point about
db-load-guc-config
- it's clumsy. I'd like to keep thedb-
prefix, though.What about
db-has-config = true|false
? Or justdb-config
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The
has
looks a bit weird inside a config option. I'll go withdb-config
, it's already much better thandb-load-guc-config
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@wolfgangwalther What do you think of having
db-config
to befalse
by defaultThe main argument for it being
true
was to have the least amount of config options: #1729 (comment). But that isn't possible atm, becausedb-anon-role
anddb-schemas
are required.However I'm thinking that only defining
db-uri
could be done and still maintain the required fields restriction. This by having anDbUriAppConfig
that is used previous toAppConfig
. With that even non-reloadable config options(likedb-pool
) could be set with thedb-config
.But anyway the above is still not done, so
db-config
is not an advantage now regarding few config options.It's just that I feel
db-config=false
is right because most users will not use it(or won't be able, as mentioned on #1729 (comment)). It's a special use case. Having it by default gives potential for errors(because of the query done, twice) on all instances.WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, a better solution for this would be to:
db-anon-role
optional. Makedb-anon-role
optional #1689db-schemas
default topublic
. This seems like a nice default that will always work. We can put a message on stdout to make it clear when the default is used.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Much, much better, yes!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the risk involved is very small. There is no overhead either - even though it's a separate statement, it's basically just part of reloading the schema cache. And in the big picture, loading config options from the database is just a tiny piece of reading the whole schema.
tbh: I actually wonder whether we really need the config option at all. It could just be enabled all the time. It's probably most useful for writing tests - but that's about it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, you're totally right here! I remember trying to do this at first, but I had some issues with the code.
I think it could be done now. We'd have to enable reloading only a part of the schema cache(the guc settings) for SIGUSR2/NOTIFY. Also make the
--dump-config
wait for theconnectionWoker
to finish(maybe an MVar) and only print the config contents to stdout(noAttempt to connect to db..
or tests fail).I think the same way now. If the guc settings are part of the schema cache, we can remove the config option.