I wrote:
> Here's v17 rebased up to HEAD.
Pushed after fooling around with the docs.
I have a couple of followup ideas in mind (\dcp and another one),
which I'll start separate threads about.
regards, tom lane
> On Apr 4, 2022, at 5:12 PM, Tom Lane wrote:
>
> Wrote it already, no need for you to do it.
Thanks!
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Mark Dilger writes:
> On Apr 4, 2022, at 2:26 PM, Tom Lane wrote:
>> So I think that instead of what you've got here, we should
>> (1) apply the map_old_guc_names[] mapping, which is constant
>> (for any one PG release anyway)
>> (2) smash to lower case
>> (3) verify validity per valid_variable_n
> On Apr 4, 2022, at 2:26 PM, Tom Lane wrote:
>
> Thanks. As I'm working through this, I'm kind of inclined to drop
> the has_parameter_privilege() variants that take an OID as object
> identifier. This gets back to the fact that I don't think
> pg_parameter_acl OIDs have any outside use; we
On 4/4/22 17:26, Tom Lane wrote:
> Mark Dilger writes:
>> [ v15 patch ]
> Thanks. As I'm working through this, I'm kind of inclined to drop
> the has_parameter_privilege() variants that take an OID as object
> identifier. This gets back to the fact that I don't think
> pg_parameter_acl OIDs ha
Mark Dilger writes:
> [ v15 patch ]
Thanks. As I'm working through this, I'm kind of inclined to drop
the has_parameter_privilege() variants that take an OID as object
identifier. This gets back to the fact that I don't think
pg_parameter_acl OIDs have any outside use; we wouldn't even have
the
> On Apr 4, 2022, at 8:36 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> If we want to backtrack to v8, that's fine. I can rebase that, port
>> some of the other changes from v14 to it, and repost it as v15.
>
> Are you working on that? I've set aside time this week to hopefully
> get this
Mark Dilger writes:
> If we want to backtrack to v8, that's fine. I can rebase that, port
> some of the other changes from v14 to it, and repost it as v15.
Are you working on that? I've set aside time this week to hopefully
get this over the finish line, but I don't want to find out that
I've b
On Wed, Mar 30, 2022 at 8:46 AM Tom Lane wrote:
> I don't want to do that with
> a blunderbuss, but perhaps there's an argument to do it for specific
> cases (search_path comes to mind, though the performance cost could be
> significant, since I think setting that in function SET clauses is
> com
Mark Dilger writes:
> Your proposal to just punt on supporting revocation of set on userset from
> public seems fine. We could revisit that in the next development cycle if
> anyone really wants to defend it. In particular, I don't see that committing
> this feature without that part would cr
On Wed, Mar 30, 2022 at 8:12 AM Andrew Dunstan wrote:
>
> On 3/30/22 09:26, Tom Lane wrote:
>
> >
> > What this loses is the ability to revoke public SET permissions
> > on USERSET GUCs. I claim that that is not so valuable as to
> > justify all the complication needed to deal with it.
Agreed,
On 3/30/22 09:26, Tom Lane wrote:
> After sleeping on it, I have a modest proposal for simplifying
> these issues. Consider this design:
>
> 1. In the SET code path, we assume (without any catalog lookup)
> that USERSET GUCs can be set. Only for SUSET GUCs do we perform
> a permissions lookup.
> On Mar 30, 2022, at 6:59 AM, Mark Dilger wrote:
>
> We should review the conversation from December and January which included
> some arguments for allowing revokes of SET on USERSET from PUBLIC. I don't
> want to keep going around in circles on this.
Hmm, I guess that conversation was m
> On Mar 30, 2022, at 6:26 AM, Tom Lane wrote:
>
> Consider this design:
Isn't that just the design I had implemented in v8 several months ago?
Subject: [PATCH v8] Allow GRANT of SET and ALTER SYSTEM SET for gucs
Allow granting of privilege to set or alter system set variables
which otherwi
After sleeping on it, I have a modest proposal for simplifying
these issues. Consider this design:
1. In the SET code path, we assume (without any catalog lookup)
that USERSET GUCs can be set. Only for SUSET GUCs do we perform
a permissions lookup. (ALTER SYSTEM does a lookup in both cases.)
2
On Wed, Mar 30, 2022 at 12:00 AM Mark Dilger
wrote:
>
> > On Mar 28, 2022, at 3:31 PM, Tom Lane wrote:
> >
> > This is what I meant by saying that you can't just refuse to GRANT on
> > unknown GUCs. It makes custom GUCs into a time bomb for dump/restore.
> > And that means you need a strategy fo
On Tue, Mar 29, 2022 at 9:00 PM Mark Dilger
wrote:
> A grant or revoke on an unrecognized custom parameter will create a SUSET
> placeholder,
[...]
> which cleans up the problem, with one exception: if the user executes a
> "revoke set on parameter some.such from public" prior to loading the
Mark Dilger writes:
> I was about to write another patch using the HookStr form, but if you are
> already editing, then I'll let you make the change. I don't see a problem
> with what you are proposing.
Don't sweat about that, I can easily rebase what I've done so far
over your updates.
I'm going to be mostly unavailable till Wednesday, but I'll leave
you with another thing to chew on:
regression=# create user joe;
CREATE ROLE
regression=# grant set on parameter plpgsql.extra_warnings to joe;
ERROR: unrecognized configuration parameter "plpgsql.extra_warnings"
This is problemat
> On Mar 28, 2022, at 2:54 PM, Tom Lane wrote:
>
> Yeah, I know it's *possible* to make this work. The question is why is
> it good to do it like this rather than to use the string API, now that
> we have the latter. AFAICS this way just guarantees that the hook must
> do a catalog lookup in
Mark Dilger writes:
>> On Mar 28, 2022, at 2:16 PM, Tom Lane wrote:
>> I just came across something odd in v12 that is still there in v13:
>> ExecGrant_Parameter uses InvokeObjectPostAlterHook not
>> InvokeObjectPostAlterHookArgStr. This seems pretty inconsistent.
>> Is there a good argument for
> On Mar 28, 2022, at 2:16 PM, Tom Lane wrote:
>
> I just came across something odd in v12 that is still there in v13:
> ExecGrant_Parameter uses InvokeObjectPostAlterHook not
> InvokeObjectPostAlterHookArgStr. This seems pretty inconsistent.
> Is there a good argument for it?
>
For SET and
I just came across something odd in v12 that is still there in v13:
ExecGrant_Parameter uses InvokeObjectPostAlterHook not
InvokeObjectPostAlterHookArgStr. This seems pretty inconsistent.
Is there a good argument for it?
... or, for that matter, why is there any such call at all?
No other GRANT/R
Mark Dilger writes:
> On Mar 28, 2022, at 11:31 AM, Tom Lane wrote:
>> I think we probably have to trash the core-regression-tests part of
>> the patch altogether and instead use a TAP test for whatever testing
>> we want to do. It might be all right to test SET privileges without
>> testing ALT
Mark Dilger writes:
> Version 12 also introduces \dcp (pneumonic, "Describe Configuration
> Parameter") for listing parameters, with \dcp+ also showing the acl, like:
The fact that that code is not dry behind the ears is painfully obvious.
It's not documented in psql-ref, not tested anywhere AFA
> On Mar 28, 2022, at 11:31 AM, Tom Lane wrote:
>
> I think we probably have to trash the core-regression-tests part of
> the patch altogether and instead use a TAP test for whatever testing
> we want to do. It might be all right to test SET privileges without
> testing ALTER SYSTEM, but I'm
I've started reviewing this patch in earnest, and almost immediately
hit a serious problem: these regression tests aren't even a little bit
committable. For one thing, they fail if you do "make installcheck"
twice in a row. This seems to be because the first run leaves some
cruft behind in pg_par
> On Mar 24, 2022, at 12:06 PM, Andrew Dunstan wrote:
>
>
> On 3/24/22 12:49, Mark Dilger wrote:
>>
>>> On Mar 17, 2022, at 8:41 AM, Andrew Dunstan wrote:
>>>
>>> If we abandoned that for this form of GRANT/REVOKE I think we could
>>> probably get away with
>>>
>>>
>>>GRANT { SET | A
On 3/24/22 12:49, Mark Dilger wrote:
>
>> On Mar 17, 2022, at 8:41 AM, Andrew Dunstan wrote:
>>
>> If we abandoned that for this form of GRANT/REVOKE I think we could
>> probably get away with
>>
>>
>> GRANT { SET | ALTER SYSTEM } ON setting_name ...
>>
>>
>> I haven't tried it, so I could b
On Thu, Mar 17, 2022 at 12:36 PM Mark Dilger
wrote:
> > On Mar 17, 2022, at 9:29 AM, Joshua Brindle
> > wrote:
> >
> > I hope this patch can be rolled
> > into the contribution from Mark.
>
> Working on it Thanks for the patch!
Great, thanks.
I missed one objectId reference (InvokeObjectDr
> On Mar 17, 2022, at 9:29 AM, Joshua Brindle
> wrote:
>
> I hope this patch can be rolled
> into the contribution from Mark.
Working on it Thanks for the patch!
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
On Thu, Mar 17, 2022 at 12:30 PM Joshua Brindle
wrote:
> I agree with this view, outside of the mixup between MAC and DAC (DAC
> is in-core, MAC is via hooks)
An excellent point! Exactly why we need expert-level help with this stuff! :-)
> So there should be some committers or contributors that
On Thu, Mar 17, 2022 at 12:04 PM Robert Haas wrote:
>
> On Thu, Mar 17, 2022 at 9:25 AM Joshua Brindle
> wrote:
> >
> >
> > > I remain of the opinion that this
> > > patch should not concern itself with that, though.
> >
> > So you are saying that people can add new object types to PG with DAC
>
On Thu, Mar 17, 2022 at 12:19 PM Mark Dilger
wrote:
> Joshua helped test the DAC portion of this patch, and answered a number of my
> questions on the topic, including in-person back in December. I take your
> point, Robert, on the general principle, but the archives should reflect that
> Josh
> On Mar 17, 2022, at 9:04 AM, Robert Haas wrote:
>
> not just in terms of telling other people how they have to write
> their patches.
...
> the burden of maintaining relatively little-used features
> should fall entirely on people who don't care about them.
Joshua helped test the DAC por
On Wed, Mar 16, 2022 at 2:47 PM Tom Lane wrote:
> Stepping back a bit ... do we really want to institutionalize the
> term "setting" for GUC variables? I realize that the view pg_settings
> exists, but the documentation generally prefers the term "configuration
> parameters". Where config.sgml u
On Thu, Mar 17, 2022 at 9:25 AM Joshua Brindle
wrote:
>
>
> > I remain of the opinion that this
> > patch should not concern itself with that, though.
>
> So you are saying that people can add new object types to PG with DAC
> permissions and not concern themselves with MAC capable hooks? Is that
On 3/17/22 10:47, Tom Lane wrote:
> Peter Eisentraut writes:
>> On 16.03.22 19:47, Tom Lane wrote:
>>> ... Perhaps we could just use "SET" and
>>> "ALTER", or "SET" and "SYSTEM"?
>> I think Oracle and MS SQL Server have many multi-word privilege names.
>> So users are quite used to that. And
Peter Eisentraut writes:
> On 16.03.22 19:47, Tom Lane wrote:
>> ... Perhaps we could just use "SET" and
>> "ALTER", or "SET" and "SYSTEM"?
> I think Oracle and MS SQL Server have many multi-word privilege names.
> So users are quite used to that. And if we want to add more complex
> privileg
On 16.03.22 19:47, Tom Lane wrote:
I'm also fairly allergic to the way that this patch has decided to assign
multi-word names to privilege types (ie SET VALUE, ALTER SYSTEM). There
is no existing precedent for that, and I think it's going to break
client-side code that we don't need to break. I
On 16.03.22 19:59, Mark Dilger wrote:
Informally, we often use "GUC" on this list, but that isn't used formally, leaving "configuration parameter" and "setting" as the
two obvious choices. I preferred "configuration parameter" originally and was argued out of it. My take on "setting" was also
> I remain of the opinion that this
> patch should not concern itself with that, though.
So you are saying that people can add new object types to PG with DAC
permissions and not concern themselves with MAC capable hooks? Is that
an official PG community stance?
On 3/16/22 16:53, Tom Lane wrote:
>> Personally I don't have problem with the use of SETTING. I think the
>> meaning is pretty plain in context and unlikely to produce any confusion.
> I'm just unhappy about the disconnect with the documentation. I wonder
> if we could get away with s/configura
Andrew Dunstan writes:
> On 3/16/22 14:47, Tom Lane wrote:
>> I'm also fairly allergic to the way that this patch has decided to assign
>> multi-word names to privilege types (ie SET VALUE, ALTER SYSTEM). There
>> is no existing precedent for that, and I think it's going to break
>> client-side c
On 3/16/22 14:47, Tom Lane wrote:
> Andrew Dunstan writes:
>> Generally I think this is now in fairly good shape, I've played with it
>> and it seems to do what I expect in every case, and the things I found
>> surprising are gone.
> Stepping back a bit ... do we really want to institutionalize
Joshua Brindle writes:
> On Wed, Mar 16, 2022 at 3:06 PM Tom Lane wrote:
>> It's going to be hard to do anything useful in a hook that (a) does
>> not know which GUC is being assigned to and (b) cannot do catalog
>> accesses for fear that we're not inside a transaction. (b), in
>> particular, se
On Wed, Mar 16, 2022 at 3:06 PM Tom Lane wrote:
>
> Mark Dilger writes:
> > On Mar 16, 2022, at 11:47 AM, Tom Lane wrote:
> >> ... I therefore judge the
> >> hook calls added to ExecSetVariableStmt and AlterSystemSetConfigFile
> >> to be 100% useless, in fact probably counterproductive because t
Mark Dilger writes:
> On Mar 16, 2022, at 11:47 AM, Tom Lane wrote:
>> ... I therefore judge the
>> hook calls added to ExecSetVariableStmt and AlterSystemSetConfigFile
>> to be 100% useless, in fact probably counterproductive because they
>> introduce a boatload of worries about whether the righ
> I suggest that what might be saner is to consider that the "objects"
> that the hook calls are concerned with are the pg_setting_acl entries,
> not the underlying GUCs, and thus that the hooks need be invoked only
> when creating, destroying or altering those entries. If we do have
> a need fo
> On Mar 16, 2022, at 11:47 AM, Tom Lane wrote:
>
> Stepping back a bit ... do we really want to institutionalize the
> term "setting" for GUC variables? I realize that the view pg_settings
> exists, but the documentation generally prefers the term "configuration
> parameters". Where config.
Andrew Dunstan writes:
> Generally I think this is now in fairly good shape, I've played with it
> and it seems to do what I expect in every case, and the things I found
> surprising are gone.
Stepping back a bit ... do we really want to institutionalize the
term "setting" for GUC variables? I r
On 3/15/22 16:59, Mark Dilger wrote:
>> On Mar 6, 2022, at 3:27 PM, Tom Lane wrote:
>>
>> Mark Dilger writes:
>>> The existing patch allows grants on unknown gucs, because it can't know
>>> what guc an upgrade script will introduce, and the grant statement may need
>>> to execute before the g
Mark Dilger writes:
> On Mar 6, 2022, at 2:57 PM, Tom Lane wrote:
>> I don't think this is materially different from what we do with
>> permissions on (say) functions. If you want to revoke the public
>> SET privilege on some USERSET variable, you instantiate the default
>> and then revoke. You
> On Mar 6, 2022, at 2:57 PM, Tom Lane wrote:
>
> I don't think this is materially different from what we do with
> permissions on (say) functions. If you want to revoke the public
> SET privilege on some USERSET variable, you instantiate the default
> and then revoke. You end up with an emp
Mark Dilger writes:
>> On Mar 6, 2022, at 2:13 PM, Tom Lane wrote:
>> ... Or, if that's our position, why are there
>> per-GUC changes at all, rather than just redefining what the
>> context values mean? (That is, why not redefine USERSET and
>> SUSET as simply indicating the default ACL to be a
> On Mar 6, 2022, at 2:13 PM, Tom Lane wrote:
>
> 1. If we need to change these two contrib modules, doesn't that imply
> a lot of changes forced on external modules as well? What are the
> security implications if somebody doesn't make such a change?
>
> 2. It looks to me like if someone in
On Thu, Dec 16, 2021 at 12:53 PM Mark Dilger
wrote:
>
>
>
> > On Dec 16, 2021, at 7:43 AM, Joshua Brindle
> > wrote:
> >
> > Ah, I understand now. Would it be possible to pass the
> > SettingAclRelationId if it exists or InvalidOid if not?
>
> SettingAclRelationId is always defined, so we can al
> On Dec 16, 2021, at 7:43 AM, Joshua Brindle
> wrote:
>
> Ah, I understand now. Would it be possible to pass the
> SettingAclRelationId if it exists or InvalidOid if not?
SettingAclRelationId is always defined, so we can always pass that value. But
the settingId itself may sometimes be In
On Wed, Dec 15, 2021 at 1:18 PM Mark Dilger
wrote:
>
> > On Dec 15, 2021, at 10:02 AM, Joshua Brindle
> > wrote:
> >
> > Ah, I was actually requesting a hook where the acl check was done for
> > setting a GUC, such that we could deny setting them in a hook,
> > something that would be useful for
> On Dec 15, 2021, at 10:02 AM, Joshua Brindle
> wrote:
>
> Ah, I was actually requesting a hook where the acl check was done for
> setting a GUC, such that we could deny setting them in a hook,
> something that would be useful for the set_user extension
> (github.com/pgaudit/set_user)
Hmm,
On Wed, Dec 15, 2021 at 10:56 AM Mark Dilger
wrote:
>
>
>
> > On Dec 14, 2021, at 2:26 PM, Joshua Brindle
> > wrote:
> >
> > currently there is a failure in check-world (not sure if it's known):
>
> That one is definitely my fault. 'en_US.UTF-8' exists on my platform, so I
> hadn't noticed. I
On Mon, Dec 13, 2021 at 5:34 PM Mark Dilger
wrote:
>
>
>
> > On Dec 13, 2021, at 1:33 PM, Mark Dilger
> > wrote:
> >
> > but will repost in a few hours
>
> ... and here it is:
currently there is a failure in check-world (not sure if it's known):
diff -U3 /src/postgres/src/test/regress/expected
> On Dec 13, 2021, at 12:56 PM, Andrew Dunstan wrote:
>
> This patch had bit-rotted slightly, and I was attempting to remedy it.
I have that already, and getting ready to post. Give me a few minutes and I'll
repost.
> However, I got a failure running the TAP tests because of this change:
>
On 11/23/21 21:14, Mark Dilger wrote:
>
>> On Nov 23, 2021, at 8:07 AM, Robert Haas wrote:
>>
>> It's my impression that information_schema is a child of the SQL
>> standard, and that inventions specific to PG go in pg_catalog.
>>
>> Also, I think the user-facing name for GUCs is "settings".
> T
On Mon, Nov 22, 2021 at 7:21 PM Mark Dilger
wrote:
> There is a new information_schema.guc_privileges view, not present in v2.
It's my impression that information_schema is a child of the SQL
standard, and that inventions specific to PG go in pg_catalog.
Also, I think the user-facing name for GU
> On Nov 16, 2021, at 7:03 AM, Robert Haas wrote:
>
> It's also going to be important to think about what happens with
> extension GUCs. If somebody installs an extension, we can't ask them
> to perform a manual step in order to be able to grant privileges. And
> if somebody then loads up a dif
On 11/17/21 12:12, Mark Dilger wrote:
>
>> On Nov 17, 2021, at 9:06 AM, Andrew Dunstan wrote:
>>
>> I agree it's not ideal. At the time I suggested a more flexible approach
>> I hadn't really thought about the problems of upgrading. If you can come
>> up with something that works there then I'll
> On Nov 17, 2021, at 9:06 AM, Andrew Dunstan wrote:
>
> I agree it's not ideal. At the time I suggested a more flexible approach
> I hadn't really thought about the problems of upgrading. If you can come
> up with something that works there then I'll be all ears.
Are you talking about upgrad
On 11/17/21 11:07, Mark Dilger wrote:
>
>> On Nov 17, 2021, at 6:31 AM, Andrew Dunstan wrote:
>>
>> Well, I was trying (perhaps not very well) to imagine how to deal with
>> someone modifying the permissions of one of the predefined roles. Say
>> pg_foo has initial permission to set bar and baz,
On Wed, Nov 17, 2021 at 9:31 AM Andrew Dunstan wrote:
> Well, I was trying (perhaps not very well) to imagine how to deal with
> someone modifying the permissions of one of the predefined roles. Say
> pg_foo has initial permission to set bar and baz, and the DBA removes
> permission to set baz. Ho
> On Nov 17, 2021, at 6:31 AM, Andrew Dunstan wrote:
>
> Well, I was trying (perhaps not very well) to imagine how to deal with
> someone modifying the permissions of one of the predefined roles. Say
> pg_foo has initial permission to set bar and baz, and the DBA removes
> permission to set ba
> On Nov 17, 2021, at 5:32 AM, Robert Haas wrote:
>
>> I was aware of that, but figured not all GUCs have to be grantable. If it
>> doesn't fit in a NameData, you can't grant on it.
>
> Such restrictions are rather counterintuitive for users, and here it
> doesn't even buy anything. Using '
On 11/16/21 17:12, Tom Lane wrote:
>
>>> To support pg_dump and pg_upgrade, it might be better to have an
>>> enabled/disabled flag rather than to delete rows.
>> I'm not really sure what this means.
> I didn't see the point of this either. We really need to KISS here.
> Every bit of added compl
On 11/17/21 08:32, Robert Haas wrote:
> On Tue, Nov 16, 2021 at 5:45 PM Mark Dilger
> wrote:
>> I was aware of that, but figured not all GUCs have to be grantable. If it
>> doesn't fit in a NameData, you can't grant on it.
> Such restrictions are rather counterintuitive for users, and here it
On Tue, Nov 16, 2021 at 5:45 PM Mark Dilger
wrote:
> I was aware of that, but figured not all GUCs have to be grantable. If it
> doesn't fit in a NameData, you can't grant on it.
Such restrictions are rather counterintuitive for users, and here it
doesn't even buy anything. Using 'text' rather
On Tue, Nov 16, 2021 at 3:38 PM Andrew Dunstan wrote:
> Your original and fairly simple set of patches used hardcoded role names
> and sets of GUCs they could update via ALTER SYSTEM. I suggested to you
> privately that a more flexible approach would be to drive this from a
> catalog table. I had
On Tue, Nov 16, 2021 at 2:48 PM Mark Dilger
wrote:
> I'm preparing a new version of the patch that has the catalog empty to begin
> with, and only adds values in response to GRANT commands. That also handles
> the issues of extension upgrades, which I think the old patch handled better
> than
> On Nov 16, 2021, at 2:12 PM, Tom Lane wrote:
>
> BTW, another objection to pg_config_param as designed here is that
> a "name" is not an appropriate way to store possibly-qualified
> custom GUC names. It's not long enough (cf. valid_custom_variable_name).
I was aware of that, but figured n
> On Nov 16, 2021, at 2:12 PM, Tom Lane wrote:
>
> The question is why you need pg_config_param at all, then.
> AFAICS it just adds maintenance complexity we could do without.
> I think we'd be better off with a catalog modeled on the design of
> pg_db_role_setting, which would have entries fo
Mark Dilger writes:
> The patch already posted on this thread already works that way. Robert and
> Tom seemed to infer that all gucs need to be present in the catalog, but in
> fact, not entering them in the catalog simply means that they aren't
> grantable. I think the confusion arose from t
> On Nov 16, 2021, at 12:38 PM, Andrew Dunstan wrote:
>
> Your original and fairly simple set of patches used hardcoded role names
> and sets of GUCs they could update via ALTER SYSTEM. I suggested to you
> privately that a more flexible approach would be to drive this from a
> catalog table.
On 11/16/21 14:48, Mark Dilger wrote:
>
>> On Nov 16, 2021, at 8:44 AM, Tom Lane wrote:
>>
>> My concern is not about performance, it's about the difficulty of
>> maintaining a catalog that expects to be a more-or-less exhaustive
>> list of GUCs. I think you need to get rid of that expectation.
> On Nov 16, 2021, at 8:44 AM, Tom Lane wrote:
>
> My concern is not about performance, it's about the difficulty of
> maintaining a catalog that expects to be a more-or-less exhaustive
> list of GUCs. I think you need to get rid of that expectation.
I'm preparing a new version of the patch
Mark Dilger writes:
> On Nov 16, 2021, at 7:28 AM, Tom Lane wrote:
>> True; as long as the expectation is that entries will exist for only
>> a tiny subset of GUCs, it's probably fine.
> I understand that bloating a frequently used catalog can be pretty
> harmful to performance. I wasn't aware
Mark Dilger writes:
> You are talking about mismatches in the other direction, aren't you? I was
> responding to Robert's point that new gucs could appear, and old gucs
> disappear. That seems analogous to new functions appearing and old functions
> disappearing. If you upgrade (not downgrad
On Tue, Nov 16, 2021 at 10:45 AM Mark Dilger
wrote:
> You are talking about mismatches in the other direction, aren't you? I was
> responding to Robert's point that new gucs could appear, and old gucs
> disappear. That seems analogous to new functions appearing and old functions
> disappearin
> On Nov 16, 2021, at 7:28 AM, Tom Lane wrote:
>
> True; as long as the expectation is that entries will exist for only
> a tiny subset of GUCs, it's probably fine.
I understand that bloating a frequently used catalog can be pretty harmful to
performance. I wasn't aware that the size of an
> On Nov 16, 2021, at 7:32 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> I don't think we support using a .so that is mismatched against the
>> version of the extension that is installed.
>
> You are entirely mistaken. That's not only "supported", it's *required*.
> Consider binary upgrade
Mark Dilger writes:
> I don't think we support using a .so that is mismatched against the
> version of the extension that is installed.
You are entirely mistaken. That's not only "supported", it's *required*.
Consider binary upgrades, where the SQL objects are transferred as-is
but the receiving
Robert Haas writes:
> On Tue, Nov 16, 2021 at 10:17 AM Tom Lane wrote:
>> Right. I think that any design that involves per-GUC catalog entries
>> is going to be an abysmal failure, precisely because the set of GUCs
>> is not stable enough.
> In practice it's pretty stable. I think it's just a m
> On Nov 16, 2021, at 7:03 AM, Robert Haas wrote:
>
> It's also going to be important to think about what happens with
> extension GUCs. If somebody installs an extension, we can't ask them
> to perform a manual step in order to be able to grant privileges.
The burden isn't on the installer o
On Tue, Nov 16, 2021 at 10:17 AM Tom Lane wrote:
> Right. I think that any design that involves per-GUC catalog entries
> is going to be an abysmal failure, precisely because the set of GUCs
> is not stable enough.
In practice it's pretty stable. I think it's just a matter of having a
plan that
Robert Haas writes:
> It's also going to be important to think about what happens with
> extension GUCs. If somebody installs an extension, we can't ask them
> to perform a manual step in order to be able to grant privileges. And
> if somebody then loads up a different .so for that extension, the
On Mon, Nov 15, 2021 at 3:37 PM Mark Dilger
wrote:
> One disadvantage of this approach is that the GUC variables are represented
> both in the list of C structures in guc.c and in the new system catalog
> pg_config_param's .dat file. Failure to enter a GUC in the .dat file will
> result in the
94 matches
Mail list logo
