Hi all,
This is my first post to the mailing list and I am looking forward to
working with everyone in the community.
With that said...
I'll take a look at changing the cache key to include user ID and
ripping out the plan invalidation logic from the current patch tomorrow
but I seriously
can see the potential
convenience of these changes, however, I'm uncertain of the necessity of
them and whether or not it opens any security concerns (again, perhaps not,
but I think it is worth asking). Also, how would this affect items like
auditing?
-Adam
--
Adam Brightwell - adam.brightw
All,
Attached is a patch with minor updates/corrections.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/src/backend/catalog/Makefile b/src/backend/catalog/Makefile
new file mode 100644
index b257b02..8cdc5cb
an
alias of another command? Or is it to add new functionality? I think the
original proposal needs to be revisited and more time needs to be spent
defining the scope and purpose of this patch.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer
that consensus has not been
reached.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
ignorance, but can you help me understand the advantage of not
having absolute path names in the COPY command?
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
as of SQL:2011 which
might make a compelling argument to leave it as is?
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
All,
FWIW, I've cleanly applied v8 of this patch to master (252e652) and
check-world was successful. I also successfully ran through a few manual
test cases.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
and updated the documentation (attached) and ran it
through some cursory testing.
At any rate, this is probably a good starting point for those changes.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/doc/src/sgml/ref
if the changes are going
to be made, then we should go ahead and do them at the same time. Though,
would it be beneficial to separate in to two distinct patches?
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
for whitespace errors
with git.
Yikes.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
Attached is two separate patches to address previous
comments/recommendations:
* superuser-cleanup-shortcuts_11-5-2014.patch
* has_privilege-cleanup_11-5-2014.patch
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git
thoughts or recommendations on how I should approach this?
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
this change as a separate
patch (as attached) or would it be preferable to include with a larger role
attribute bitmask patch?
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/src/backend/catalog/Catalog.pm b/src
would be the community preference on tracking these
attached/proposed changes? Should I create a separate entry in the next CF
for this item (seems prudent) or would it be preferred to keep it attached
to the current 'new attributes' CF entry?
Thanks,
Adam
--
Adam Brightwell - adam.brightw
recommendations beyond what has
already been discussed and proposed I'm at a bit of a loss on where to take
it. I'm all ears on this one and would certainly appreciate any feedback
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
removed? Thoughts?
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
reality or
not, but I believe it is certainly worth considering.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
discussions that influenced/motivated this patch.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
think the
array approach would be more appropriate than a string but I'm willing to
accept that neither is acceptable and would certainly be interested in
opinions.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
)
* Refactor #define's from 'parsenodes.h' to 'acl.h'
* Added #define ROLE_ATTR_ALL to represent all currently available
attributes.
* Added genbki.pl substitution for PGROLEATTRALL constant.
Please let me know what you think, all feedback is greatly appreciated.
Thanks,
Adam
--
Adam Brightwell
ROLE_ATTR_BYPASSRLS (17)
+ #define N_ROLE_ATTRIBUTES 8
+ #define ROLE_ATTR_NONE 0
These shouldn't need to be here any more..?
No they shouldn't, not sure how I missed that.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/src/test/modules/dummy_seclabel/Makefile b/src/test/modules/dummy_seclabel/Makefile
new file mode 100644
index 72049d4..d93c964
*** a/src/test/modules/dummy_seclabel/Makefile
--- b
All,
I have attached an updated patch that incorporates the feedback and
recommendations provided.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/src/backend/access/transam/xlogfuncs.c b/src/backend
(ROLEATTR_BLAH)' which handles doing the
GetUserId() itself. That'd simplify quite a few of the above calls.
Good point. Added.
Attached is an updated patch.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/src
good. I'll start on those changes next.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
to be pursued. If a simple move is
possible/acceptable, then I think that would be the best option. I can
handle that as it would appear that I am capable of moving it, if that is
acceptable.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer
found the option to do
so. Let's see what shows up with your work.
I have moved it to commitfest 2014-12 and marked as Waiting on Author if
that is acceptable.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
discussed.
I have attached an updated patch with initial documentation changes for
review.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
new file mode
it for
consideration if others concur.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/src/backend/libpq/auth.c b/src/backend/libpq/auth.c
new file mode 100644
index 9ad99ce..2b2dbb3
*** a/src/backend/libpq/auth.c
--- b/src/backend
in 'check_role_attribute' and the documentation
updates requested by Stephen.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
new file mode 100644
index 9ceb96b
! Thanks, I appreciate it!
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
.
If these seem reasonable, then I'll begin updating the initial/current
patch submitted. But in either case, feedback and suggestions are
certainly welcome and appreciated.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
* DUMP - allows role to perform pg_dump* backups of whole database
* MONITOR - allows role to view pg_stat_* details (as originally proposed)
* PROCSIGNAL - allows role to signal backend processes (as originally
proposed)well
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
that specific functionality, though short of adding a
'has_rolsuper' function that will raise an appropriate error, I'm uncertain
of an approach. Thoughts?
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/doc/src
discussion and decided it is probably best to keep
it as a separate patch/effort. I'd certainly be willing to continue that
discussion and assist in moving any related effort forward, therefore,
please let me know if there is anything I can do to help.
Thanks,
Adam
--
Adam Brightwell
, while PHYSBACKUP seems like it'd cover what
REPLICATION already does.
Thoughts?
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
message level
seems possible; or confusion about whether this is a permission that
lets you log things.
That's a good point. I'll change this one up.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
* Adam Brightwell (adam.brightw...@crunchydatasolutions.com) wrote:
Given this discussion, I have attached a patch that removes CATUPDATE for
review/discussion.
Thanks!
I've added this patch (up-thread) to the next CommitFest (2015-02).
-Adam
--
Adam Brightwell - adam.brightw
All,
I have attached and updated patch for review.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/doc/src/sgml/catalogs.sgml b/doc/src/sgml/catalogs.sgml
new file mode 100644
index 62305d2..fd4b9ab
On Mon, Jan 5, 2015 at 11:49 AM, Robert Haas robertmh...@gmail.com wrote:
On Wed, Dec 24, 2014 at 12:48 PM, Adam Brightwell
adam.brightw...@crunchydatasolutions.com wrote:
* BACKUP - allows role to perform backup operations
* LOGROTATE - allows role to rotate log files
* MONITOR - allows
by rolsuper.
Ah yes, that's a good point. I have updated and attached a new version of
the patch.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
remove-catupdate-v2.patch
Description: Binary data
--
Sent via pgsql-hackers
to their
products with a minimal impact.
Thoughts?
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
' for reference as well,
FWIW, I have also attached a patch that corrects this issue for me,
hopefully it is useful.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/contrib/sepgsql/expected/label.out b/contrib/sepgsql
we need.
I agree with #1 on this.
#1 makes sense to me as well. The current version of the patch takes this
approach. Also, I have verified against 'master' as of c6ee39b.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer
that they are actually removed at the next
possible opportunity. Otherwise, I'd probably lean towards just removing
them now and getting it over with.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
, however, is that important enough to note given that it was not
allowed previously?
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
of the forms of this attribute. Personally,
I think it is easier to read with the underscore. But, ultimately, I
defaulted to no underscore to remain consistent with the other attributes,
such as CREATEDB and CREATEROLE.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
is not the bottleneck).
Thanks for sharing this info. I'm looking forward to getting my hands on
an rpi2 soon for some of my other projects. Having an idea of the
increased performance, especially related to compilation, was certainly
something I was curious about.
-Adam
--
Adam Brightwell
Really? Why? I would think it's the policy's job to restrict relabel
operations.
I agree. This seems like an unnecessary change.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
include a 'bar' related role. That seems like a bad idea,
IMHO. Maybe it can't be avoided, but I'd expect that only relevant
information for the database being dumped would be included.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer
missing or not understanding about how this
should work, but this doesn't seem right.
Thoughts?
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
beyond the current scope.
Though, I thought I'd throw it out there.
Also, I think this would potentially conflict with what FabrÃzio is
doing with CURRENT_DATABASE on COMMENT, though, I think it might be a
preferable solution.
https://commitfest.postgresql.org/5/229/
-Adam
--
Adam Brightwell
and tablespaces? No need to change their treatment.
Yes, those. Ok.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
/dive into this one further.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql
and pg_shdescription. I would
make non-creating pg_dump reproduce none of those.
I think the bigger question is Where is the line drawn between
pg_dump and pg_dumpall?. At what point does one tool become the
other?
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database
wouldn't bother unless there is an actual change.
Understood. Thanks.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription
> In commit 5d1ff6bd559ea8df I'd expected that the
> WARNINGs would certainly show up in regression test output, and I thought
> I'd verified that that was the case --- did that not happen for you?
I just doubled checked with both 'check' and 'check-world' and neither
seemed to have an issue with
On Tue, Nov 10, 2015 at 9:18 AM, Adam Brightwell
<adam.brightw...@crunchydata.com> wrote:
>> I'm with Alvaro: the most interesting question here is why that mistake
>> did not blow up on you immediately. I thought we had enough safeguards
>> in place to catch this typ
>> @@ -3365,6 +3370,8 @@ RelationCacheInitializePhase3(void)
>> AuthIdRelationId);
>> load_critical_index(AuthMemMemRoleIndexId,
>> AuthMemRelationId);
>> +
>> >> #define NUM_CRITICAL_SHARED_INDEXES 5/* fix if you change list
>> >> above */
>> >>
>> >
>> > Need to bump this #define? If you didn't get the error that this is
>> > supposed to throw, perhaps there's a bug somewhere worth investigating.
>>
>> Hmm... I thought that I had, are you
Hi All,
While working on an auth hook, I found that I was unable to access the
pg_shseclabel system table while processing the hook. I discovered
that the only tables that were bootstrapped and made available at this
stage of the the auth process were pg_database, pg_authid and
pg_auth_members.
> I'm with Alvaro: the most interesting question here is why that mistake
> did not blow up on you immediately. I thought we had enough safeguards
> in place to catch this type of error.
Ok, I'll explore that a bit further as I was able to build and use
with my hook without any issue. :-/
-Adam
>> +1 for adding to the next commitfest.
>>
> Me also.
Done.
-Adam
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
of the context changes make sense to me. However, I am still
seeing some errors in the regression tests. The errors look like they
are solely based around log messages and not 'functionality'. I have
attached the 'regression.diffs' for reference.
-Adam
--
Adam Brightwell - adam.brightw
is the only
version that will work as-is on EL6 but it is what it is for now, I
suppose.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
/unconfined_r
field unlike unconfined_t domain.
I have reviewed and tested this patch against 'master' at 781ed2b.
The patch applies without issue and all tests pass on EL7.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
So what about the buildfarm animal that was offered for this? We still
have this module completely uncovered in the buildfarm ...
I believe that is in the works and should be made available soon.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer
t would obviously negate
my concern.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
to either be the owner of the table or a member of
the role that owns it, right? Given that, if by definition the policy
definer is not allowed to do anything other than define policies, then
obviously putting such a role in the table owners group would allow it
to do much more, correct?
anted to solicit for comment before moving forward with
> that since we don't have a consensus about if this should be done.
I'm not sure that I understand the previous concerns around this bit
well enough to speak intelligently on this point. However, with that
said, I believe the changes ma
od by most (if not
all) DBA's I have spoken with about it.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http
e
documentation side of this issue.
Thoughts or comments?
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
transaction-isolation-rls-docs.patch
Description: Binary data
--
Sent via pgsql-hackers mailing list (pgsql-ha
ed and are accepted at this isolation level, then I'm not sure
how we can reasonably expect locking the rows to have any affect.
Though, again, I'm willing to accept that I am not fully understanding
this behavior and that I am completely wrong.
-Adam
--
Adam Brightwell - adam.brightw...
> I think conversations like this are a part of why we have trouble attracting
> new contributors (of any gender) to the community.
+1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
extern PsqlSettings pset;
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
would RLS experts find it beneficial for me to take care of those?
>
> That would be awesome, but I would say that if we do #1 & 2 for 9.5, we
> also need #3.
Agreed. Please let me know if there is anything I can do to help.
-Adam
--
Adam Brightwell - adam.brig
> 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to policies
I believe this one has already been addressed by Stephen
(20150910192313.gt3...@tamriel.snowman.net)? Are there further
considerations for his proposed changes?
-Adam
--
Adam Brightwell - adam.brig
r mirror/archive site to
support it, like gmane or spinics. This is just my opinion though.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to y
> Pushed, with one cosmetic change (update comment on formrdesc). I also
> bumped the catversion, but didn't verify whether this is critical.
Excellent! Thanks!
-Adam
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
> So this looks like a bugfix that we should backpatch, but on closer
> inspection it turns out that we need the rowtype OID to be fixed, which
> it isn't unless this:
>
>> -CATALOG(pg_shseclabel,3592) BKI_SHARED_RELATION BKI_WITHOUT_OIDS
>> +CATALOG(pg_shseclabel,3592) BKI_SHARED_RELATION
> Thanks for the report and the fix.
Yup. I have added it to the 2016-11 commitfest:
https://commitfest.postgresql.org/11/794/
> This seems a rather basic error to occur a year after release.
>
> Is this a problem with the testing of RLS? What other RLS related
> failures exist in other
All,
I have discovered a bug with the COPY command, specifically related to RLS.
The issue:
When running COPY as superuser on a table that has RLS enabled, RLS is
bypassed and therefore no issue exists. However, when performing a
COPY as a non-privileged user on the same table causes issues
> Looking for and improving test coverage for RLS is a good suggestion,
> but let's not link the fate of the issue reported here with this
> requirement. I have spent some time looking at this patch and this
> looks in rather good shape to me (you even remembered to use the
> prefix regress_* for
I've given an initial review of this patch. It applies cleanly and
compiles without issue as of 6da9759. I'm going to continue with
testing it against a set of RADIUS servers in the next few days. But
in the meantime, I have a few questions (below).
> It supports multiple RADIUS servers. For all
>> I wonder if removing the complexity of maintaining two separate lists
>> for the server and port would be a better/less complex approach. For
>> instance, why not go with a list of typical 'host:port' strings for
>> 'radiusservers'? If no port is specified, then simply use the default
>> for
On Mon, Mar 6, 2017 at 10:24 AM, Adam Brightwell
<adam.brightw...@crunchydata.com> wrote:
>>> I wonder if removing the complexity of maintaining two separate lists
>>> for the server and port would be a better/less complex approach. For
>>> instance, why not go
88 matches
Mail list logo
