thers
(perhaps the same xids but viewed elsewhere) will be 32 bit. That might make
it difficult for users to match them up.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 2, 2020, at 2:13 PM, Andres Freund wrote:
>
> Hi,
>
> On 2020-04-02 11:47:32 -0700, Mark Dilger wrote:
>> I agree with transitioning to 64-bit xids with 32 bit xid/epoch pairs
>> as an internal implementation and storage detail only, but we still
>>
ing in the docs seems to explain the abbrevation. See
doc/src/sgml/func.sgml
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 4, 2020, at 7:11 AM, Thomas Munro wrote:
>
> On Sat, Apr 4, 2020 at 4:45 AM Mark Dilger
> wrote:
>> FYI, (not the responsibility of this patch), we never quite define what the
>> abbreviation "xip" stands for. If "Active xid8s at the time
> On Jan 15, 2022, at 12:28 AM, Julien Rouhaud wrote:
>
> Could you send a rebased version?
Yes. Here it is:
v4-0001-Reject-patterns-with-too-many-parts-or-wrong-db.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ific task.
Wow, that's totally contrary to how I see this patch. The heart and soul of
this patch is to fix the fact that CREATEROLE is currently overpowered.
Everything else is gravy.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ing. Do
we at least agree on the mischief-abatement aspect of this patch set?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
te_server_files IN ROLE pg_write_server_files;
+ERROR: must have admin option on role "pg_write_server_files"
CREATE ROLE regress_execute_server_program IN ROLE pg_execute_server_program;
+ERROR: must have admin option on role "pg_execute_server_program"
CREATE ROLE regress_signal_backend IN R
a tenant with CREATEROLE. Can you give me the bit?
Or does the fact that you lack the bit mean you can't give it to me, either?
Other suggestions?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
to change all these
other things; we'd be breaking a lot more, and features that appear more
commonly used.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
tterns-with-too-many-parts-or-wrong-db.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
---
substr_test: first, second
(1 row)
SELECT substr_test.substring('first' FROM 'second');
ERROR: syntax error at or near "FROM"
LINE 1: SELECT substr_test.substring('first' FROM 'second');
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
N" implied for all attributes when not
specified.
I'd appreciate feedback on the direction this patch is going.
v8-0001-Adding-admin-options-for-role-attributes.patch.WIP
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
rolcanlogin;/* allowed to log in as session user? */
>> bool rolreplication; /* role used for streaming replication
>> */
>> boolrolbypassrls; /* bypasses row-level security? */
>> +
>> +booladminherit; /* allowed to administer
>> inherit? */
>> +booladmcreaterole; /* allowed to administer createrole? */
>> +booladmcreatedb;/* allowed to administer createdb?? */
>> +booladmcanlogin;/* allowed to administer login? */
>> +booladmreplication; /* allowed to administer replication? */
>> +booladmbypassrls; /* allowed to administer bypassesrls? */
>> +booladmconnlimit; /* allowed to administer connlimit? */
>> +booladmpassword;/* allowed to administer password? */
>> +booladmvaliduntil; /* allowed to administer validuntil? */
>> int32 rolconnlimit; /* max connections allowed (-1=no
>> limit) */
>
> It's cosmetic, but the space between rolbypassrls and adminherit is
> maybe not needed, and I'd put rolconnlimit first (even though it has a
> different type).
Oh, totally agree. I had that blank there during development because the
"rol..." and "adm..." all started to blur together.
Thanks again! If the patch stays mostly like it is, I'll incorporate all your
review comments into a next version.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
way non-Superusers can assign groups to other users?
Yes, by having ADMIN on those groups.
> I
> feel this (next to creating users/groups) is the primary thing those
> CREATEROLE admins are supposed to do/where doing up to now.
Right. In the past, having CREATEROLE implied having ADMIN on every role. I'm
intentionally breaking that.
> The way the adm* privs are now somewhere in the middle of the rol*
> privs also looks weird for the end-user and there does not seems to be
> some greater scheme behind it:
Because they are not variable length nor nullable, they must come before such
fields (namely, rolpassword and rolvaliduntil). They don't really need to come
before rolconnlimit, but I liked the idea of packing twelve booleans together,
since with "bool" typedef'd to unsigned char, that's twelve contiguous bytes,
starting after oid (4 bytes) and rolname (64 bytes) and likely fitting nicely
without padding bytes on at least some platforms. If I split them on either
side of rolconnlimit (which is 4 bytes), there'd be seven bools before it and
five bools after, which wouldn't pack nicely.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
the comment.
>> Whether "WITH ADMIN OPTION" or "WITHOUT ADMIN OPTION" is implied hinges on
>> whether the role is given CREATEROLE. That hackery is necessary to preserve
>> backwards compatibility. If we don't care about compatibility, I could
>> change the patch to make "WITHOUT ADMIN OPTION" implied for all attributes
>> when not specified.
>
> Given the relative size of the changes we're talking about regarding
> CREATEROLE, I don't really think we need to stress about backwards
> compatibility too much.
Yeah, I'm leaning pretty strongly that way, too.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
think the ADMIN stuff *would* be the way to go, but for it's weird
self-administration feature. That to me seems to kill the idea. What do you
think?
> Perhaps there is a need to have a user who has all of the above
> capabilities and maybe that would be an 'owner' or 'manager', but as I
> tried to illustrate above, there's definitely use-cases for giving
> a role only some of the above capabilities rather than all of them
> together at once.
I'm using the terms "owner"/"manager" without regard for whether they have all
those abilities or just some of them. However, I think these terms don't apply
for just the traditional ADMIN option on the role. In that case, calling it
"ownership" or "managership" is inappropriate.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
too restrictive, and we need a
way to specify, attribute by attribute, how this works. Is this just a problem
of surprising grammar? Is it surprising behavior? If the latter, I'm inclined
to give up this WIP as having been a bad move. If the former, I'll try to
propose some less ob
ommitted in time for postgres 15. If not,
then I'm probably going to stop working on this until next year, because at
this point, we don't have enough time to finish.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
rticle rather than skipping down to that
section.
I hope it helps
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
test also disables autovacuum, so a background auto-analyze
shouldn't be running. Maybe that's why you haven't seen amcheck fall over?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
h is well written. Patch 0004 feels like something that won't get
committed. The INHERITCREATEDROLES and SETCREATEDROLES in 0004 seems clunky.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
't rather that it always work one way or always
the other. It's just to say that I don't want it to work differently based on
some poorly advertised property of the role executing the command.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
articular CREATEROLE
> user by revoking the implicit grants with CASCADE.
>
> But since this implicit grant has, and must have, the bootstrap
> superuser as grantor, it is also only reasonable that superusers get
> to determine what options are used when creating that grant, rather
> than leaving that up to the CREATEROLE user.
Yes, this all makes sense, but does it entail that the CREATE ROLE command must
behave differently on the basis of a setting?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
herself, so she gets the behavior she wants? I'm confused now
about who controls these settings.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ng tools can tell when
Alice circumvents these settings. Without that bit, the whole thing is inane.
Why make Alice jump through hoops that you are explicitly allowing her to jump
through? Apparently the answer is that you can point a high speed camera at
the hoops.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
bout how hard it is to
de-conflate role membership from role administration, and maybe that's a
non-starter for reasons I don't recall at the moment. I expect Robert has
already contemplated that idea and instead proposed this patch for good
reasons. Robert?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
mean here? Are you inventing a new syntax?
+GRANT bob TO alice WITH SET FALSE, INHERIT FALSE, ADMIN TRUE;
+ERROR: syntax error at or near "SET"
+LINE 1: GRANT bob TO alice WITH SET FALSE, INHERIT FALSE, ADMIN TRUE...
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Nov 28, 2022, at 12:33 PM, Mark Dilger
> wrote:
>
>> Isn't this just GRANT .. WITH SET FALSE, INHERIT FALSE, ADMIN TRUE? That
>> should allow role administration, without actually granting membership in
>> that role, yet, right?
>
> Can yo
#x27;);
+ random_normal
+---
+ NaN
+(1 row)
+
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t, looked up in pg_extension join
pg_namespace, and substituted back in.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 14, 2021, at 2:47 PM, Vik Fearing wrote:
>
> On 4/14/21 7:36 PM, Tom Lane wrote:
>> Mark Dilger writes:
>>>> On Apr 13, 2021, at 3:26 PM, Tom Lane wrote:
>>>> However I think we may still need an assumption that earthdistance
>>>>
> On Apr 14, 2021, at 10:17 AM, Robert Haas wrote:
>
> On Mon, Apr 12, 2021 at 11:06 PM Mark Dilger
> wrote:
>> It now reports:
>>
>> # heap table "postgres"."public"."test", block 0, offset 18, attribute 2:
>> # toast v
g this so late in the
development cycle.
I'd also like your impressions on whether we're likely to move contrib/amcheck
into core anytime soon. If so, is it worth adding an option that we'll soon
need to deprecate?
v1-0001-Adding-install-missing-option-to-pg_amcheck.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 18, 2021, at 6:19 AM, Andrew Dunstan wrote:
>
> how about specifying pg_catalog as the schema instead of public?
Done.
v2-0001-Adding-install-missing-option-to-pg_amcheck.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The E
t of testing without
> any attempt at version compatibility.
>
> We can revisit compatibility further in the next release.
Sounds good.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 19, 2021, at 9:32 AM, Andrew Dunstan wrote:
>
>
> On 4/18/21 7:32 PM, Alvaro Herrera wrote:
>> On 2021-Apr-18, Andrew Dunstan wrote:
>>
>>> On 4/17/21 3:43 PM, Mark Dilger wrote:
>>>> I'd also like your impressions on whether w
> problematic, and we should be prepared to make the necessary moves then.
This was the request that motivated the move to src/bin.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 19, 2021, at 10:25 AM, Jehan-Guillaume de Rorthais
> wrote:
>
> On Mon, 19 Apr 2021 12:37:08 -0400
> Andrew Dunstan wrote:
>
>>
>> On 4/19/21 10:43 AM, Mark Dilger wrote:
>>>
>>>> On Apr 19, 2021, at 5:11 AM, Andrew Dunstan w
re
> tests and review...
I did that, too, in the 0002 version of my patch. Perhaps we need to merge
your work and mine.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 19, 2021, at 12:50 PM, Robert Haas wrote:
>
> On Thu, Apr 15, 2021 at 1:07 PM Mark Dilger
> wrote:
>> I have added the verb "has" rather than "contains" because "has" is more
>> consistent with the phrasing of other similar c
it might *feel* like pg_amcheck and amcheck have to both be
installed to work, but I don't think that point of view makes much sense in
reality. The computer running the client and the computer running the server
are frequently not the same computer.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 19, 2021, at 8:06 PM, Michael Paquier wrote:
>
> On Mon, Apr 19, 2021 at 07:15:23PM -0700, Mark Dilger wrote:
>> There is another issue to consider. Installing pg_amcheck in no way
>> opens up an avenue of attack that I can see. It is just a client
>>
> On Apr 19, 2021, at 9:22 PM, Michael Paquier wrote:
>
> On Mon, Apr 19, 2021 at 08:39:06PM -0700, Mark Dilger wrote:
>> This is a classic privilege escalation attack. Bob has one
>> privilege, and uses it to get another.
>
> Bob is a superuser, so it has all
> On Apr 20, 2021, at 5:54 AM, Robert Haas wrote:
>
> On Tue, Apr 20, 2021 at 1:31 AM Mark Dilger
> wrote:
>> I think you are conflating the concept of an operating system adminstrator
>> with the concept of the database superuser/owner.
>
> You should
> On Apr 20, 2021, at 5:54 AM, Robert Haas wrote:
>
> On Tue, Apr 20, 2021 at 1:31 AM Mark Dilger
> wrote:
>> I think you are conflating the concept of an operating system adminstrator
>> with the concept of the database superuser/owner.
>
> You should
> On Apr 20, 2021, at 3:19 PM, Tom Lane wrote:
>
> Mark Dilger writes:
>>> On Apr 20, 2021, at 5:54 AM, Robert Haas wrote:
>>> On Tue, Apr 20, 2021 at 1:31 AM Mark Dilger
>>> wrote:
>>>> I think you are conflating the concept of an operati
es $1 in the first
> regex and make it capturing itself, so you get "devel" in $2, and decide
> based on its presence/absence? Then you don't have to pop and push a -1.
The first regex should match things like "12", "12.1", "14devel", or those same
> On Apr 19, 2021, at 5:07 PM, Mark Dilger wrote:
>
>
>
>> On Apr 19, 2021, at 12:50 PM, Robert Haas wrote:
>>
>> On Thu, Apr 15, 2021 at 1:07 PM Mark Dilger
>> wrote:
>>> I have added the verb "has" rather than "contains"
> On Apr 23, 2021, at 10:28 AM, Robert Haas wrote:
>
> On Thu, Apr 22, 2021 at 7:28 PM Mark Dilger
> wrote:
>> I have refactored the patch to address your other concerns. Breaking the
>> patch into multiple pieces didn't add any clarity, but refactoring p
> On Apr 23, 2021, at 10:31 AM, Mark Dilger
> wrote:
>
> I will test your patch and see what differs.
Here are the differences between master and you patch:
UPDATE $toastname SET chunk_seq = chunk_seq + 1000 WHERE chunk_id =
$value_id_to_corrupt
- qr/${
> On Apr 23, 2021, at 11:05 AM, Mark Dilger
> wrote:
>
> Here are the differences between master and you patch:
Another difference I should probably mention is that a bunch of unrelated tests
are failing with errors like:
toast value 13465 chunk 0 has size 1995, but expect
> On Apr 23, 2021, at 11:29 AM, Robert Haas wrote:
>
> On Fri, Apr 23, 2021 at 2:15 PM Mark Dilger
> wrote:
>> Another difference I should probably mention is that a bunch of unrelated
>> tests are failing with errors like:
>>
>>toast value 13465
tly, the final
chunk will have size TOAST_MAX_CHUNK_SIZE, but you're expecting no larger than
one less than that, given how modulo arithmetic works.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
till suffers the same failures. I'll try to post something that
accomplishes the changes to the reports that you are looking for.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 23, 2021, at 3:01 PM, Mark Dilger wrote:
>
> I'll try to post something that accomplishes the changes to the reports that
> you are looking for.
The attached patch changes amcheck corruption reports as discussed upthread.
This patch is submitted for the v14 devel
> On Apr 30, 2021, at 9:39 AM, Robert Haas wrote:
>
> On Mon, Apr 26, 2021 at 1:52 PM Mark Dilger
> wrote:
>> The attached patch changes amcheck corruption reports as discussed upthread.
>> This patch is submitted for the v14 development cycle as a bug fix, per
&g
> On Apr 30, 2021, at 11:56 AM, Robert Haas wrote:
>
> On Fri, Apr 30, 2021 at 2:31 PM Mark Dilger
> wrote:
>> Just to be clear, I did not use your patch v1 as the starting point.
>
> I thought that might be the case, but I was trying to understand what
> you d
+ else if (expected_chunk_seq <= last_chunk_seq)
because otherwise it won't complain if the only missing chunk is the very last
one.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
it was trying to deal with this issue.
Thoughts?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
omalous for hard to articulate
reasons not quite the same as but akin to mismatched verb aspect.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Apr 30, 2021, at 1:04 PM, Mark Dilger wrote:
>
>> toast value %u was expected to end at chunk %d, but ended while
>> expecting chunk %d
>>
>> i.e. same as the currently-committed code, except for changing "ended
>> at" to "ended wh
e could, for example
SET log_parser_stats TO off;
Thanks
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
s decide which controls would allow the tenant to escape the specific
sandbox the provider has designed?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On May 1, 2021, at 7:07 AM, Chapman Flack wrote:
>
> On 04/30/21 22:00, Mark Dilger wrote:
>> Viewing all of this in terms of which controls allow the tenant to escape
>> a hypothetical sandbox seems like the wrong approach. Shouldn't we let
>> service provi
SET
CUSTOM_OPTIONS GUCs, or we could extend those functions to take a config_group
option, or perhaps some of both. I haven't thought too much yet about whether
allowing extensions to place a custom GUC into one of the predefined groups
would be problematic. Any thoughts on tha
ks-to-amcheck.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
section provides an overview of TOAST (The Oversized-Attribute Storage
> Technique).
Thanks for reviewing! Changed to:
+ /* Toasted attributes too large to be untoasted should never be stored */
v2-0001-Adding-more-toast-pointer-checks-to-amcheck.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
approach appears better in this regard.
Admin+Security seems sufficient, in conjunction with Chapman's idea of
extensible check_hooks.
Thoughts?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On May 13, 2021, at 10:41 AM, Stephen Frost wrote:
>
> Greetings,
>
> * Mark Dilger (mark.dil...@enterprisedb.com) wrote:
>>> On May 12, 2021, at 12:58 PM, Robert Haas wrote:
>>> - Group things by which section of postgresql.conf they're in, and
>
> On May 13, 2021, at 12:18 PM, Jacob Champion wrote:
>
> On Thu, 2021-05-13 at 11:42 -0700, Mark Dilger wrote:
>> The distinction that Theme+Security would make is that capabilities
>> can be categorized by the area of the system:
>> -- planner
>&g
on? Should they succeed, in which case
the docs should mention that "refresh" is not the only valid
set_publication_option?
Something else, perhaps?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On May 21, 2021, at 10:39 PM, Bharath Rupireddy
> wrote:
>
> On Sat, May 22, 2021 at 1:49 AM Mark Dilger
> wrote:
>>
>> -hackers,
>>
>> I think commit 82ed7748b710e3ddce3f7ebc74af80fe4869492f created some
>> confusion that should be clean
esql.org/message-id/flat/CALDaNm34qugTr5M0d1JgCgk2Qdo6LZ9UEbTBG%3DTBNV5QADPLWg%40mail.gmail.com
Sure, and thanks for the link!
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On May 24, 2021, at 5:37 PM, Ranier Vilela wrote:
>
> Hi,
>
> Possible pointer TupleDesc rettupdesc used not initialized?
>
> if (!isNull) at line 4346 taking a true branch, the function
> check_sql_fn_retval at line 4448 can use rettupdesc uninitialized.
Care to
> On May 28, 2021, at 6:42 AM, Alvaro Herrera wrote:
>
>>>> On Mar 4, 2020, at 7:43 PM, Mark Dilger
>>>> wrote:
>
>>>> as mentioned in [1], I have created an implementation of command
>>>> counter statistics very similar in purpose t
> On May 27, 2021, at 11:06 PM, Noah Misch wrote:
>
> On Tue, May 25, 2021 at 01:33:54PM -0700, Mark Dilger wrote:
>> v3-0001 adds a new pg_logical_replication role with permission to manage
>> publications and subscriptions.
>
>> v3-0004 adds a new pg_database
es. One advantage of Jeff's idea of using a server object
rather than a string is that it becomes more plausibly safe to allow the
subscription owner to make changes to that attribute of the subscription.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
aving Charlie, not Bob, as the "run-as" user helps somewhere
right around (D).
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
to give responsibility for
> those objects to different and especially mutually untrusting users?
When public repositories of data, such as the IANA whois database, publish
their data via postgres publications.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
s
> supposed to defend himself against Alice, and Bob doesn't even seem to
> be trying. Maybe we should rename the users to Samson and Delilah? :-)
No, Atahualpa and Pizarro.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ogically only
touching the lefthand side, so you should then have a (nonsuperuser-creator,
nonsuperuser-owner) pair. But you don't. You go the apparently needless extra
step of just squashing them together. I just don't see why it needs to be like
that.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
ason why one patch should both split owner
> from run-as user and also allow the owner to be a non-superuser. That
> seems like two different efforts to me.
I don't have a concrete problem with your patch, and wouldn't object if you
committed it. My concerns were more how you were phrasing things, but it seems
not worth any additional conversation, because it's probably a distinction
without a difference.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
end (intentionally or otherwise) and add some tables from the
> "locally_controlled_stuff" schema, we'll refuse to replicate that into
> our eponymous schema.
That example is good, though I don't see how "filters" are better than
roles+privileges. Care to elaborate?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
e perl tap tests you've included appear to do
this (except indirectly when calling test_client); grep'ing for the libpq error
message "parameter with forced encryption is not to be encrypted" in the tests
has no matches. Is it just not possible? I thought you'd m
> On Feb 11, 2023, at 1:54 PM, Mark Dilger wrote:
>
> Here are some observations
I should mention, src/sgml/html/libpq-exec.html needs clarification:
> paramFormats[]Specifies whether parameters are text (put a zero in the array
> entry for the corresponding parameter) o
ackendStartup(port=0x7f9edc804080) at postmaster.c:4252:3
frame #25: 0x00010c690d0e postgres`ServerLoop at postmaster.c:1745:7
frame #26: 0x00010c68e23a postgres`PostmasterMain(argc=8,
argv=0x7f9edac06440) at postmaster.c:1417:11
frame #27: 0x00010c565249 postgres`main(
ve documentation) and later return a copy of the
slot's tuple sans any "system columns" (also per the above documentation) and
that's when the core code breaks. It's not the TAM that is broken here, not
according to the interface's documentation as I read it. Am I reading it wrong?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
comment to remove mention of the
> Asserts. I also tried to form the comment in a way that's more
> understandable about why we always write a "0" in "INSERT 0 ".
Your wording is better. +1
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
e privileges, it sounds like you mean
privileges on the publishing database. But then you talk about CREATE
SUBSCRIPTION granting privileges, which would necessarily be on the subscriber
database. Can you clarify what you have in mind?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
I thought "run as"
was the Windows option for this.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
d your original
proposal as only restricting the value of search_path within security definer
functions. This idea would allow you to restrict it everywhere, and not
tailored to just that context.
[1] https://www.postgresql.org/message-id/608c9a81.3020...@anastigmatix.net
—
Ma
ber of cases to be worth
implementing. What are your thought on that?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jun 3, 2021, at 12:06 PM, Pavel Stehule wrote:
>
>
>
> čt 3. 6. 2021 v 20:25 odesílatel Mark Dilger
> napsal:
>
>
> > On Jun 3, 2021, at 9:38 AM, Pavel Stehule wrote:
> >
> > This design looks good for extensions, but I am not sure if i
is triggered. You can see the stack trace by opening
tmp_check/log/021_truncate_subscriber.log
v1-0001-Adding-test-to-trigger-logical-replication-assert.patch
Description: Binary data
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
suitable Portal. I speculated about
> that in the commit message for 84f5c2908da, but I don't feel like
> taking point on such work.
I'll dig into this a bit more.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
t the sending server didn't send an invalid subtransaction id.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
> On Jun 9, 2021, at 1:52 PM, Bossart, Nathan wrote:
>
> I'd be happy to clean it up and submit it for
> discussion in pgsql-hackers@ if there is interest.
Yes, I'd like to see it. Thanks for offering.
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The
Since I failed to apply the patches and didn't test them,
> I may have overlooked something but I didn't find the
> corresponding codes.
Do you believe that functionality should be added? I have not thought much
about that issue.
—
Mark Dilger
EnterpriseDB: http://www.enterpri
aw no change,
which is fine. I was looking for regressions where the estimates are now worse
than before. Do you expect there to be any such cases?
—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
501 - 600 of 980 matches
Mail list logo
