On Mon, Mar 6, 2017 at 10:24 AM, Adam Brightwell
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 with a list of typical 'host:port
>> 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 t
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
> 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 t
> 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 commands?
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 whe
> 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:
http://www.postgre
> 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 BKI_ROWT
> 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
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 type of error.
>
> Ok, I'll e
>> +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
> 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
>> >> #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
>> @@ -3365,6 +3370,8 @@ RelationCacheInitializePhase3(void)
>> AuthIdRelationId);
>> load_critical_index(AuthMemMemRoleIndexId,
>> AuthMemRelationId);
>> + load_cri
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.
UPDATE can address
for this specific case. If inconsistencies in the 'snapshot' can be
expected 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
it. Perhaps this, plus an additional paragraph which goes into
>> more detail about exactly what's going on?
>
> I'm still thinking about it, but I think you have the right idea here.
I have attached a patch for review that I believe addresses the
documentation side of this issu
intuitive and easily understood 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
is also needs more polish and regression
> tests, but I wanted 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 intellige
7;t depend on some other 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@postgr
> 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
d 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
." So that 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
ither 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?
-Adam
-
el is
better than nothing, IMHO. Kind of a bummer that 9.1 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 m
> 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 En
al years.
> So, I thought it has less risk to rely on unconfined_u/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 Brigh
empty list. I'm willing to accept that there might be
something here that I am 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.crunchydatasolu
n when I dump 'foo', in this manner, wouldn't I also be
including 'user2'? Said differently, a restore of a 'foo'-only dump
would also include a 'bar' related role. That seems like a bad idea,
IMHO. Maybe it can't be avoided, but I
et a little tricky.
>
> Like roles 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@postg
robably a
considerable undertaking and certainly 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://commitf
reakage after each such run is
> large.
>
> All in all, I 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 mailin
datacl, pg_db_role_setting, pg_shseclabel 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 -
it up and propose removing this redundant
#include from objectaddress.h.
If it makes sense to do so, I have attached a patch that removes it.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/src/include/ca
the TODO would be great.
I'd be willing to look/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
.
All 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
--
A
>
> 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
represents
0 AD/CE, 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
the issue. I have attached the 'regression.diffs' 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/con
ve adequate time,
opportunity and information to make the appropriate changes to their
products with a "minimal" impact.
Thoughts?
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
fore, I think having them read from 'rolsuper' for the
time being would be ok, provided 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
; is one more concept than 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...@cr
d it as one 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...@crunchydat
s 10 card (30MB/s but the I/O 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 wa
t rid of that whole check, not just replace rolcatupdate 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
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
*** a
ticularly like LOGBACKUP and don't
think it really makes sense, while PHYSBACKUP seems like it'd cover what
REPLICATION already does.
Thoughts?
-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
--
A
; > future log related operations
>
> Maybe LOGFILE? Only because some confusion with the LOG 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
lieve that
topic needs much further 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
On Mon, Jan 5, 2015 at 11:49 AM, Robert Haas wrote:
> On Wed, Dec 24, 2014 at 12:48 PM, Adam Brightwell
> wrote:
> > * BACKUP - allows role to perform backup operations
> > * LOGROTATE - allows role to rotate log files
> > * MONITOR - allows role to view pg_stat_*
an error. Perhaps this
is OK, but my concern would be on the expected behavior around items like
'has_table_privilege'. My natural thought would be that we would want to
preserve that specific functionality, though short of adding a
'has_rolsuper' function that will raise an ap
originally proposed)
* LOG - allows role to rotate log files - remains broad enough to consider
future log related operations
* DUMP - allows role to perform pg_dump* backups of whole database
* MONITOR - allows role to view pg_stat_* details (as originally proposed)
* PROCSIGNAL - allo
e to signal backend processes.
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
s.)
That's fantastic! Thanks, I appreciate it!
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
ion (Assert) check 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
I have attached a patch that fixes 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..2b2
le attributes being
> 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/sg
tually I could have done it, just 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
n the CF app.
>
This work will certainly continue 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..
to play around with it but it all seems pretty clean to
> me and will allow us to easily add the additiaonl role attributes being
> discussed.
Sounds good. I'll start on those changes next.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
, but we can't do that as discussed in
> the comment (which I like).
>
Agreed. Fixed.
> > ! /* role attribute check routines */
> > ! extern bool has_role_attribute(Oid roleid, RoleAttr attribute);
> > ! extern bool check_role_attribute(Oid roleid, Role
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
addresses this issue.
Thanks,
Adam
--
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/mo
;2)
> > + #define ROLE_ATTR_CREATEDB (1<<3)
> > + #define ROLE_ATTR_CATUPDATE (1<<4)
> > + #define ROLE_ATTR_CANLOGIN (1<<5)
> > + #define ROLE_ATTR_REPLICATION (1<<6)
> > + #define ROLE_ATTR_BYPASSRLS (1<<7)
> > + #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 Engineer - www.crunchydatasolutions.com
quot;,Login,Replication,"Bypass RLS"}
(1 row)
* 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 w
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
approach might be that the above function return a string of comma
separated attributes, similar to what \du in psql does. IMO, I think the
array approach would be more appropriate than a string but I'm willing to
accept that neither is acceptable and would certainly b
t
same overarching thread. The two provided, I believe are sufficient to
lead to any prior relevant discussions that influenced/motivated this patch.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
t a bitmask was certainly more efficient. However, I know
that an array would be more extensible given that we could envision more
than 64 role attributes. I'm uncertain if that is a potential reality or
not, but I believe it is certainly worth considering.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
then be treated like every other attribute and
the coupling with superuser removed? Thoughts?
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
o handling pg_roles, etc. before updating.
Thanks,
Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
diff --git a/src/backend/catalog/Catalog.pm b/src/backend/catalog/Catalog.pm
new file mode 100644
index eb91c53..523b379
*** a/s
to just make it more consistent with the rest of our
> permission-check error messages..), are there any other opinions on the
> wording? Would be great to get feedback on that..
>
Agreed, I would certainly be willing to move these changes forward as a
separate effort, but wi
Also, what 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 Brightwe
). Would it be better to include 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
uld be better just to ask.
Any thoughts or recommendations on how I should approach this?
-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 a
r redundant and unnecessary,
IMO.
Also, your patch has spaces between tabs. Check for whitespace errors
> with git.
>
Yikes.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
lly. IMHO, I think 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
08832...@sss.pgh.pa.us
I have taken that patch 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.crun
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
1038718...@sss.pgh.pa.us
Now this is from 2002 and it appears it wasn't necessary to change at the
time, but I haven't yet found anything else related (it's a big archive).
Though, as I understand it, PUBLIC is now non-reserved 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
of this is not having absolute path names in the COPY command.
Pardon my 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
objects, specifically rules and
policies?
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
e to it.
Certainly not and I am in no way confused that consensus has not been
reached.
-Adam
--
Adam Brightwell - adam.brightw...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
and ALTER ROLE syntax (which I think I
could see some value in). However, I think it has been taken beyond just
resolving the inconsistency and started to cross over into feature creep.
Is the intent simply to resolve inconsistencies between what is now an
alias of another command?
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
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...@crunchydatasolutions.com
Database Engineer - www.crunchydatasolutions.com
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 do
91 matches
Mail list logo
