I agree with that, but it also makes sense to me to drop
the example in 14, when the operation it describes is also dropped. If the
committer who picks this up wants to drop that example now, that's fine, too.
v3-0001-Adding-deprecation-notices.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Aug 30, 2020, at 11:50 AM, Tom Lane wrote:
>
> Mark Dilger writes:
>> [ v3-0001-Adding-deprecation-notices.patch ]
>
> Pushed with some fiddling.
Thanks!
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
hods are used does the Oid get written. This
second option seems closer to the implementation that you already have, because
you already handle the decompression of data where the Oid is lacking, so all
you have to do is intentionally not write the Oid when compressing using pglz.
O
t that whole issue.
>
> Right. I never meant anything like making a would-be
> bt_index_parent_check() call into a bt_index_check() call, just
> because of the state of the system (e.g., it's in recovery). That
> seems awful, in fact.
Please find attached the latest version of the patc
or perhaps a WARNING)
rather than an error. That's not what happens now, but if you'd rather we
fixed this problem that way, I can go do that, or perhaps as the author of the
bt_*_check functions, you can do that and I can just do the pg_amcheck changes.
How shall we proceed?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
nefit. Somebody could quite
reasonably complain about this on a hot standby with millions of unlogged
relations. Actual ERROR messages might get lost in all the noise.
It's true that these NOTICEs do not change the return code. I was thinking
about the ERRORs we get on failed lock acqui
that documentation
style.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
not a warning box.
Should that be changed also?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
check, while still
> fixing everything that needs to be fixed in pg_amcheck.
Your proposal sounds good. Let me try it and get back to you shortly.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 11, 2021, at 12:25 PM, Mark Dilger
> wrote:
>
> Your proposal sounds good. Let me try it and get back to you shortly.
Ok, I went with this suggestion, and also your earlier suggestion to have a
in the pg_amcheck docs about using --parent-check and/or
--rootdes
> On Oct 11, 2021, at 2:33 PM, Peter Geoghegan wrote:
>
> On Mon, Oct 11, 2021 at 1:20 PM Mark Dilger
> wrote:
>> Ok, I went with this suggestion, and also your earlier suggestion to have a
>> in the pg_amcheck docs about using --parent-check and/or
>> --
ion=# \d regresion.public.bit_defaults
> | Table "public.bit_defaults"
> |...
I can only assume that you are intentionally misspelling "regression" as
"regresion" (with only one "s") as part of the test. I have not checked if
that w
cept any amount of nonsense you like:
foo=# \d nonesuch.foo.a.b.c.d.bar.baz
Table "bar.baz"
Column | Type | Collation | Nullable | Default
+-+---+--+-
i | integer | | |
Is this something we'
a
correctly named database.schema.table, but v13 psql accepted
lots.of.nonsense.schema.table, and neither of those seems at first glance to be
correct. But perhaps there are good reasons for ignoring the nonsense prefixes?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
z"
Column | Type | Collation | Nullable | Default
+-+---+--+-
i | integer | | |
I expect I'll have to submit a patch restoring the old behavior, but I wonder
if that's the best direction to go.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
nce we have clients
that understand the full database.schema.relation format without ignoring the
database portion, our client behavior is getting inconsistent. I'd like to
leave the door open for someday supporting server.database.schema.relation
format, too. I was just wondering when i
the time the parallel workers run
the command. I don't know how important that is.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
uot; means to make it accept database.schema.table or whether it means to
accept any.prefix.at.all.schema.table. It sounds like more people like the
latter, so I'll go with that unless this debate rages on and a different
conclusion is reached.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
cidentally changed in the future, and will
repost after doing so.
string_utils.patch.WIP
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
.mytable
was ever legitimate. You got exactly the same results with \d
nosuchdb.myschema.mytable, meaning the user was given a false sense of security
that the database name was being used to fetch the definition from the database
they specified.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 12, 2021, at 10:54 AM, Robert Haas wrote:
>
> On Tue, Oct 12, 2021 at 1:18 PM Mark Dilger
> wrote:
>> Here is a WIP patch that restores the old behavior, just so you can eyeball
>> how large it is.
>
> I guess that's not that bad. Why did we
> On Oct 12, 2021, at 10:18 AM, Mark Dilger
> wrote:
>
> Here is a WIP patch that restores the old behavior, just so you can eyeball
> how large it is. (It passes check-world and I've read it over once, but I'm
> not ready to stand by this as correct
script stops
working because somebody created database db2. Maybe that's not completely
horrible, but surely it is less than ideal.
3b is what pg_amcheck does. It accepts database.schema.relname, and it will
complain if no matching database/schema/relation can be found (unless
--no-strict-names was given.)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 13, 2021, at 8:43 AM, Robert Haas wrote:
>
> On Wed, Oct 13, 2021 at 10:40 AM Mark Dilger
> wrote:
>> 3a is a bit strange, when considered in the context of patterns. If db1,
>> db2, and db3 all exist and each have a table foo.bar, and psql is connected
&
fix is just one line. Thoughts?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t looks.
I'm curious if the test is indicating something about the underlying test
system. Only one other test in the tree uses background_psql(). I was hoping
Andrew would have something to say about whether this is a bug with that
function or just user error on my part.
—
Mark Dilger
Ente
owards parallel testing from perl. Or do you have a
different way forward for that?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ndrew wanted to jump in. Having
heard nothing, I guess you can revert it.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 19, 2021, at 12:28 PM, Jeff Davis wrote:
>
> On Mon, 2021-09-27 at 11:15 -0700, Mark Dilger wrote:
>> Allow non-superusers to create event triggers. The logic already
>> existed and is unchanged to handle event triggers owned by non-
>> superusers and
> On Oct 19, 2021, at 3:18 PM, Jeff Davis wrote:
>
> On Tue, 2021-10-19 at 13:17 -0700, Mark Dilger wrote:
>> Wouldn't it be much cleaner to have superuser bypass the trigger?
>
> Maybe it could be a user property like "BYPASS_EVENT_TRIGGERS", and
> on
> On Oct 13, 2021, at 1:43 PM, Mark Dilger wrote:
>
> The issue of name parsing impacts pg_dump and pg_dumpall, also. Consider
> what happens with:
>
> pg_dump -t production.critical.secrets > secrets.dump
> dropdb production
>
> In v13, if your default datab
redict such things in the
face of corruption, especially when considering that the index scan code might
be modified in the future. I'm not claiming there is no room for improvement
here -- likely there is -- but it is not simple, and the patch that would
result would be larger than the patch actually being reviewed. I'd rather
leave such a project for another day.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
d, though I can understand the confusion. That
is, in fact, a small part of why I'm splitting the patches into different email
threads.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
't mean by this to cut
anyone out of the discussion.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
llow-event-trigger-ownership-by-non-superusers.patch
Description: Binary data
v1-0002-Allow-regular-users-to-create-event-triggers.patch
Description: Binary data
[1]
https://www.postgresql.org/message-id/flat/F9408A5A-B20B-42D2-9E7F-49CD3D1547BC%40enterprisedb.com
—
Mark Dilger
Enterpri
inary data
v1-0004-Restrict-power-granted-via-CREATEROLE.patch
Description: Binary data
[1]
https://www.postgresql.org/message-id/flat/F9408A5A-B20B-42D2-9E7F-49CD3D1547BC%40enterprisedb.com
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
sers.patch
Description: Binary data
v1-0003-Respect-permissions-within-logical-replication.patch
Description: Binary data
[1]
https://www.postgresql.org/message-id/flat/F9408A5A-B20B-42D2-9E7F-49CD3D1547BC%40enterprisedb.com
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise
> On Oct 20, 2021, at 11:42 AM, Greg Stark wrote:
>
>
>
> On Wed., Oct. 20, 2021, 12:41 Mark Dilger,
> wrote:
>
> I used a switch statement to trigger a compiler warning in such an event.
>
> Catching better compiler diagnostics is an excellent reason
Over in [1], you wrote:
> On Oct 20, 2021, at 11:27 AM, Jeff Davis wrote:
>
> On Wed, 2021-10-20 at 10:32 -0700, Mark Dilger wrote:
>> I'd like to have a much clearer understanding of Noah's complaint
>> first. There are multiple things to consider: (1) the rol
le basis (i.e., ALTER ROLE OWNER TO). I
> haven't looked at this new patch set too closely, so my apologies if
> this has already been added.
Yes, I completely agree with you on that. Both REASSIGN OWNED BY and ALTER
ROLE OWNER TO should work. I'll take a look at the patches a
erhaps? But whatever it is, the reasoning about who gets audited
and who does not must be clear enough that Batman can pass a compliance audit.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
by the authority to ALTER SYSTEM SET can be granted per
GUC rather than having predefined roles which hardcoded privileges.
I have not withdrawn the ALTER SYSTEM SET patches yet, as I don't know if
Andrew's proposal can be made to work, but I wouldn't recommend tying this
> On Oct 25, 2021, at 10:09 PM, Shinya Kato
> wrote:
>
> On 2021-10-21 03:40, Mark Dilger wrote:
>> These patches have been split off the now deprecated monolithic
>> "Delegating superuser tasks to new security roles" thread at [1].
>> The purpose o
in the perf profiles after this change)
It appears fmtint only has three options for base, being 10, 16, and 8. Have
you profiled with either of the others special cased as well? I don't see much
use in optimizing for octal, but hexadecimal is used quite a bit in wal with
patterns like &quo
ithout a more precise description
of the index algorithm.
Perhaps the OP might want to cite a paper describing a particular index
algorithm for us to review?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
for privilege checking, instead use has_privs_of_role()
be added to the header for is_member_of_role() without needing the new wrapper
function?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
List of roles
Role name |Owner| Attributes
| Member of | Description
-+-+----+-+-
mark.d
e C is a member of role D" is
too confusing for people to ever keep straight, then perhaps we need something
like "tenant" to help lessen the confusion.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
cts and
privileges that the owner itself has rights to assign.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
re important to close the race condition in an OWNER TO than for a
DISABLE.
Thoughts?
alter_subscription_race.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t appealing).
I am not strongly against adding syntactic support for FOR ALL ROLES vs. FOR
role, role, ..., so long as that syntax cannot expand the net. It does seem a
bit arbitrary to me, though, since you could also say FOR HOURS OF DAY 11PM
through 3AM, and once you open the door to supporting all that in the syntax,
and tracking it in the catalogs, you've opened a can of worms.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
esn't own by roles that "joe" doesn't own. Maybe "own" here should be "have
ADMIN on", but it has to be something.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ou want this, but I don't understand why you think it is tied
to a security patch. I'm not being facetious when I mention having syntax to
support event triggers to fire only at certain times of day. Plenty of
deployments I have encountered have exactly this type of restriction, limiting
the time of day when certain sorts of actions can be performed. Similarly, I
have seen deployments which have their heaviest activity around the Christmas
shopping season. They might want event triggers that fire between Black Friday
and Boxing Day that prevent schema changes during such heavy load, but not the
rest of the year. And they might want them to fire for some roles and not
others.
The idea in the event trigger patch is to make it reasonable, from a security
standpoint, to allow non-superusers to create event triggers. The only thing
that makes it *unreasonable* for them to do so is that an event trigger could
block or alter actions performed by roles which the non-superuser trigger owner
should not have the privilege to block or alter. So restrictions on when the
event trigger fires to get around that problem seem on topic. Other filters, no
matter how good the idea, are simply off topic. Go and implement them with my
blessing. But I don't see why I should have to implement them as part of this
patch set.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
d, but I don't know to what you are referring.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 1, 2021, at 10:58 AM, Mark Dilger wrote:
>
> ALTER SUBSCRIPTION..[ENABLE | DISABLE] do not synchronously start or stop
> subscription workers. The ALTER command updates the catalog's subenabled
> field, but workers only lazily respond to that. Disabl
> On Nov 1, 2021, at 10:58 AM, Mark Dilger wrote:
>
> ALTER SUBSCRIPTION..[ENABLE | DISABLE] do not synchronously start or stop
> subscription workers. The ALTER command updates the catalog's subenabled
> field, but workers only lazily respond to that. Disabl
> On Nov 3, 2021, at 12:07 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>> [ v1-0001-Reject-patterns-with-too-many-parts-or-wrong-db.patch ]
>
> This needs a rebase over the recent renaming of our Perl test modules.
> (Per the cfbot, so do several of yo
> On Oct 20, 2021, at 12:06 PM, Mark Dilger
> wrote:
>
> Ok. How about:
Done that way.
v3-0001-Adding-more-toast-pointer-checks-to-amcheck.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Oct 1, 2021, at 12:34 PM, Mark Dilger wrote:
>
> The patch does it this way.
A rebased patch is attached.
v2-0001-Reject-storage-options-in-toast-namespace-in-view.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise P
dy committed would seem to
confuse matters if any new issues were to arise. We can come back to this
sometime in the future, if need be.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
sion about which
database(s) were processed.
Consistent with how we allow db.schemapat.relpat in pg_dump and psql,
also allow db.schemapat for specifying schemas, as:
\dn mydb.myschema
in psql and
pg_dump --schema=mydb.myschema
Fix the pre-v14 behavior of ignoring leading portions of p
tion: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
going in for v15? (I'm not taking a
position here, just asking what you'd prefer.)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
#x27;s the starting point for an index
> scan -- it is the TID that is stored in indexes that needs to be
> stable over time. And so pruning needs to leave behind coherent
> looking whole entire HOT chains, just as we ought to verify that
> pruning consistently gets it right.
Thanks, Peter, for this analysis. It's getting a bit late in the day, but I'll
try this out tomorrow, I expect.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 5, 2021, at 8:56 PM, Tom Lane wrote:
>
> Some of the buildfarm is unimpressed with this --- looks like the test
> output is less stable than you thought.
Yes, it does. I had to play with it a bit to be sure the test itself is
faulty, and I believe that it is.
—
nflicts?
I'm cc'ing Andrew to get his thoughts about the buildfarm integration
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
nefits from this
syntax. I would expect the amount of locking and checking for pre-existing
roles that such logic would require would make the IF NOT EXIST option useless.
Perhaps I'm wrong?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
y could be addressed in
a series of follow-on patches?
I understand this idea is not as useful for creating idempotent scripts, but
maybe it gets you part of the way there?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
erhaps this would be ok if all roles granted into "charlie" had
grantor="super_alice". I'm not sure that is really good enough, but it is a
lot closer to making this safe than allowing the command to succeed when role
"charlie" has been granted away by someone else.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
roles which alice owns.
This sounds reasonable. It means, of course, implementing a role ownership
system. I thought you had other concerns about doing so.
> I appreciate that the case of 'super_alice' doing things where they're
> an actual superuser might still be an issue, but running around doing
> things with superuser is already risky business and the point here is to
> get away from doing that by splitting superuser up, ideally in a way
> that privileges can be given out to non-superusers in a manner that's
> safer than doing things as a superuser and where independent
> non-superusers aren't able to do bad things to each other.
I'm not sure what to do about this.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
future work on roles may
benefit if we close the testing gap.
For consideration:
v1-0001-Add-test-for-REVOKE-ADMIN-OPTION.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 16, 2021, at 6:31 AM, Daniel Gustafsson wrote:
>
>> On 16 Nov 2021, at 00:58, Mark Dilger wrote:
>
>> While working on a fix for dangling references to dropped roles in the
>> pg_auth_members.grantor field, I happened to notice we entirely lack
>>
ones, changes function signatures, or whatever. The
same is true here for GUCs.
I don't think we support using a .so that is mismatched against the version of
the extension that is installed.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> 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 "supp
is than I'm aware? It can be a bit challenging to run performance
tests on such things, given the way everything interacts with everything else.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 16, 2021, at 10:08 AM, Jeff Davis wrote:
>
> On Mon, 2021-11-01 at 10:58 -0700, Mark Dilger wrote:
>> It is unclear .
>>
>> Thoughts?
>
> What if we just say that OWNER TO must be done by a superuser, changing
> from one superuser to
ich is probably just as well,
> since it's work that I'd be wanting to reject.
Yeah, that's why I didn't write it. I wanted feedback on the basic
implementation before doing that work.
> (Hm, but actually,
> doesn't pg_dump need work anyway to dump t
> On Nov 16, 2021, at 12:06 PM, Andrew Dunstan wrote:
>
> There doesn't seem to be a CF item for it but I'm
> inclined to commit it in a couple of days time.
https://commitfest.postgresql.org/36/3414/
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
his means. Are you suggesting that the (or in your formulation ) should have a "bool enabled"
field, and when the guc gets dropped, the "enabled" field gets set to false?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ation parameters to be proper objects with OIDs and with entries in
pg_depend and/or pg_shdepend. Maybe there is some better way to do it, but
that's why I've been doing this.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
verify that it is unique. (We wouldn't want multiple records for the
same pair.)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 16, 2021, at 8:11 PM, Jeff Davis wrote:
>
> On Wed, 2021-11-03 at 12:50 -0700, Mark Dilger wrote:
>> The first two patches are virtually unchanged. The third updates the
>> behavior of the apply workers, and updates the documentation to
>> match.
>
>
#x27;t understand why this table has as the primary
> key rather than just guc.
I was responding to Tom's recommendation that I follow the pattern in
pg_db_role_setting, and speculating how that would work. I was not proposing
to do it that way.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
So it amuses me that we'd now be
talking about granting some of these to predefined roles, as that is a
regression in flexibility. (How would a site revoke it from one of those
predefined roles if they wanted a different policy?)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
tter problem would
seem to be a mere matter of programming, something I'm working on but don't
have finished. (But maybe you see dragons ahead for me that I'm not seeing
yet?)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
patch. The only sense in which this patch depends on that issue is that this
patch proposes that non-superuser subscription owners are already an issue, and
therefore that this patch isn't creating a new issue, but rather making more
sane something that already can happen.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
vilege bits and define
new privileges that can be granted per subscription rather than globally. (I
think that last one is a non-starter, but just mention it as an example of
another approach.)
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
rights that only have meaning for subscriptions is
going to be accepted. For full disclosure, I'm proposing adding ACL_SET and
ACL_ALTER_SYSTEM in another patch and my proposal there could get shot down for
the same reasons, but I think your argument would be even harder to defend.
Maybe oth
> On Nov 17, 2021, at 1:06 PM, Jeff Davis wrote:
>
> On Wed, 2021-11-17 at 10:25 -0800, Mark Dilger wrote:
>> We may eventually allow non-superusers to create subscriptions, but
>> there are lots of details to work out.
>
> I am setting aside the idea of s
with how the system is already designed to work. You can't drop the
subscription's owner without first running REASSIGN OWNED, or ALTER
SUBSCRIPTION..OWNER TO, or simply dropping the subscription:
DROP ROLE regress_subscription_user;
ERROR: role "regress_subscription_user" cannot be dropped because some
objects depend on it
DETAIL: owner of subscription regress_testsub
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ons without noticing
the change. Now, it is limited to finishing the current transaction. Would
you prefer that the worker noticed the change in ownership and aborted the
transaction on the subscriber side? Or should the ALTER SUBSCRIPTION..OWNER TO
block? I don't see much advantage to eith
TO .. behavior. Is there a reason why 0003* patch (or
> something on those lines) shouldn't be considered to be applied?
Jeff Davis and I had a long conversation off-list yesterday and reached the
same conclusion. I will be submitting a version of 0003 which does not depend
on the prior t
t, but consider it a WIP patch
until then.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
has outstanding issues to be
resolved, so I can't be sure if runas would be helpful, but it might.
Table triggers might benefit from having a runas role. I don't have a proposal
here, just an intuition that we should think about this before designing how
"runas" works.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 19, 2021, at 7:25 AM, Mark Dilger wrote:
>
> Jeff Davis and I had a long conversation off-list yesterday and reached the
> same conclusion. I will be submitting a version of 0003 which does not
> depend on the prior two patches.
Renamed as 0001 in version 3, as
catalog with a bunch of entries that aren't needed.
Grants on GUCs create a new catalog entry if necessary, or update the existing
catalog entry if found.
There is a new information_schema.guc_privileges view, not present in v2.
v3-0001-Allow-GRANT-of-SET-and-ALTER-SYSTEM-for-
(ctx->tuphdr->t_infomask & HEAP_XMAX_COMMITTED)
{
if (ctx->tuphdr->t_infomask & HEAP_XMAX_LOCK_ONLY)
... report something ...
else if ((ctx->tuphdr->t_infomask & (HEAP_XMAX_IS_MULTI | HEAP_LOCK_MASK))
== HEAP_XMAX_EXCL_LOCK)
... report a different thing ...
}
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ving that,
which they may not be, it is an extra round trip to the customer asking for
stuff.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
v9.2 or earlier are (or
become) rare, servers initialized that far back which have been upgraded one or
more times since then may be common.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
change, and possibly one we do not
want. Can we consider this out of scope?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
201 - 300 of 980 matches
Mail list logo
