On 01/24/2014 10:12 AM, Craig Ringer wrote:
> (Re-sending; I forgot to cc the list)
>
> On 01/20/2014 02:15 PM, Craig Ringer wrote:
>> On 01/20/2014 09:58 AM, Craig Ringer wrote:
>>> As it is I'm spending today reworking the RLS patch on top of the new
>>> approach to updatable security barrier vi
On 01/18/2014 03:27 AM, Gregory Smith wrote:
> With my advocacy hat on, I'd like to revisit this idea now that there's
> a viable updatable security barrier view submission. I thought the most
> serious showstopper feedback from the last CF's RLS submission was that
> this needed to be sorted out
On 12/13/13 11:40 PM, Craig Ringer wrote:
You may want to check out the updated writable security-barrier views patch.
http://www.postgresql.org/message-id/52ab112b.6020...@2ndquadrant.com
It may offer a path forward for the CF submission for RLS, letting us
get rid of the var/attr fiddling tha
On 2013-12-14 05:40, Craig Ringer wrote:
I find the heirachical and non-heirachical label security model used in
Teradata to be extremely interesting and worthy of study.
The concept is that there are heirachical label policies (think
"classified", "unclassified", etc) or non-heirachical (mutual
On 12/14/2013 11:24 AM, Gregory Smith wrote:
>
>
> Things I can already see to work on here are:
>
> -Fix the regression tests
> -Catch up to master again
I've got much of that in the tree:
https://github.com/ringerc/postgres/tree/rls-9.4
--
Craig Ringer http://www.2ndQuad
On 12/14/2013 11:24 AM, Gregory Smith wrote:
> The RLS feature set available with the CF submission is good enough
> for those projects to continue exploring PostgreSQL
You may want to check out the updated writable security-barrier views patch.
http://www.postgresql.org/message-id/52ab112b.602
On Thu, Nov 7, 2013 at 9:08 PM, Craig Ringer wrote:
> On 11/07/2013 09:47 PM, Greg Stark wrote:
>> Incidentally I still feel this is at root the problem with updateable
>> views in general. I know it's a bit off to be tossing in concerns from
>> the peanut gallery when I'm not actually offering to
On Wed, Nov 6, 2013 at 1:38 AM, Craig Ringer wrote:
> (a) Updatable views are implemented in the rewriter, not the planner.
> The rewriter is not re-run when plans are invalidated or when the
> session authorization changes, etc. This means that we can't simply omit
> the RLS predicate for superus
On 11/07/2013 06:11 PM, Dean Rasheed wrote:
> I don't really get this part of the discussion. Why would you want to
> make updatable SB views do any of that?
I don't, especially. If we're going to use updatable SB views as the
basis for RLS then we need the option to skip adding the qual for super
On 11/07/2013 09:47 PM, Greg Stark wrote:
> Incidentally I still feel this is at root the problem with updateable
> views in general. I know it's a bit off to be tossing in concerns from
> the peanut gallery when I'm not actually offering to work on it and
> others are having putting in serious ef
On Wed, Nov 6, 2013 at 6:38 AM, Craig Ringer wrote:
> That's the approach I've been considering. There are a few wrinkles with
> it, though:
>
> (a) Updatable views are implemented in the rewriter, not the planner.
> The rewriter is not re-run when plans are invalidated or when the
> session auth
On 6 November 2013 19:12, Kohei KaiGai wrote:
> 2013/11/6 Craig Ringer :
>> On 11/05/2013 09:36 PM, Robert Haas wrote:
>>> I haven't studied this patch in detail, but I see why there's some
>>> unhappiness about that code: it's an RLS-specific kluge. Just
>>> shooting from the hip here, maybe we
2013/11/6 Craig Ringer :
> On 11/05/2013 09:36 PM, Robert Haas wrote:
>> I haven't studied this patch in detail, but I see why there's some
>> unhappiness about that code: it's an RLS-specific kluge. Just
>> shooting from the hip here, maybe we should attack the problem of
>> making security-barri
All,
Just a comment: I'm really glad to see the serious work on this. If RLS
doesn't make it into 9.4, it'll be because the problems of RLS are
fundamentally unsolvable, not because we didn't give it our best. Great
work, all!
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
S
On 6 November 2013 09:23, Craig Ringer wrote:
> On 11/06/2013 05:02 PM, Dean Rasheed wrote:
>
>> The basic idea is to have rewriteTargetView() collect up any quals
>> from SB views in a new list on the target RTE, instead of adding them
>> to the main query's predicates (it needs to be a list of S
On 11/06/2013 05:02 PM, Dean Rasheed wrote:
> The basic idea is to have rewriteTargetView() collect up any quals
> from SB views in a new list on the target RTE, instead of adding them
> to the main query's predicates (it needs to be a list of SB quals, in
> case there are SB views on top of other
On 11/05/2013 09:36 PM, Robert Haas wrote:
> I haven't studied this patch in detail, but I see why there's some
> unhappiness about that code: it's an RLS-specific kluge. Just
> shooting from the hip here, maybe we should attack the problem of
> making security-barrier views updatable first, as a
On Mon, Nov 4, 2013 at 8:46 PM, Craig Ringer wrote:
> On 11/04/2013 11:17 PM, Robert Haas wrote:
>> I'd still like to here what's wrong with what I said here:
>>
>> http://www.postgresql.org/message-id/ca+tgmoyr1phw3x9vnvuwdcfxkzk2p_jhtwc0fv2q58negcx...@mail.gmail.com
>
> For me, just my understan
On 11/04/2013 11:17 PM, Robert Haas wrote:
> I'd still like to here what's wrong with what I said here:
>
> http://www.postgresql.org/message-id/ca+tgmoyr1phw3x9vnvuwdcfxkzk2p_jhtwc0fv2q58negcx...@mail.gmail.com
For me, just my understanding. I'm still too new to the planner and
rewriter to grasp
On Mon, Nov 4, 2013 at 9:37 AM, Tom Lane wrote:
> Craig Ringer writes:
>> On 09/04/2013 11:22 PM, Tom Lane wrote:
>>> AFAICT, to deal with update/delete the RLS patch needs to constrain order
>>> of qual application without the crutch of having a separate level of
>>> subquery; and it's that beha
Craig Ringer writes:
> On 09/04/2013 11:22 PM, Tom Lane wrote:
>> AFAICT, to deal with update/delete the RLS patch needs to constrain order
>> of qual application without the crutch of having a separate level of
>> subquery; and it's that behavior that I have zero confidence in, either
>> as to wh
On 09/04/2013 11:22 PM, Tom Lane wrote:
> AFAICT, to deal with update/delete the RLS patch needs to constrain order
> of qual application without the crutch of having a separate level of
> subquery; and it's that behavior that I have zero confidence in, either
> as to whether it works as submitted
Because of CF-2nd end, it was moved to the next commit-fest.
In my personal opinion, it probably needs a few groundwork to get RLS
commitable,
prior to RLS itself.
One is a correct handling towards the scenario that Korotkov pointed
out. (How was
it concluded?) I think it is a problem we can fix
On Wed, 2013-09-04 at 14:35 +, Robert Haas wrote:
>
> On Fri, Aug 30, 2013 at 3:43 PM, Tom Lane wrote:
> > I think it's entirely sensible to question whether we should reject
> (not
> > "hold up") RLS if it has major covert-channel problems.
>
> We've already had this argument before, about
Now I'm trying to tackle the covert-channel problem that Korotkov
pointed out at upthread.
The attached patch works "almost" well. It prevents to print number of
rows being filtered
if the target plan node is under sub-query with security-barrier
attribute; because row-
level security feature is c
On Wed, 2013-08-28 at 13:56 +0200, Kohei KaiGai wrote:
> The attached patch fixed the portion I was pointed out, so its overall
> design has not been changed so much.
The documentation doesn't build:
openjade:catalogs.sgml:237:28:X: reference to non-existent ID
"CATALOG-PG-ROWLEVELSEC"
--
S
Kohei KaiGai writes:
> 2013/9/4 Tom Lane :
>> And for insert/update/delete, we do what exactly?
> Regarding to update/delete, this patch also enhanced to allow update or
> delete mechanism allows to take a sub-query on top of the table scan plan.
> So, its explain output shows as follows:
> pos
On Wed, Sep 4, 2013 at 11:22 AM, Tom Lane wrote:
>> The same mechanism will prevent UPDATE and DELETE from seeing any rows
>> the user shouldn't be able to touch.
>
> No, it won't, because we don't support direct update/delete on views
> (and if you look, you'll notice the auto-updatable-view stuf
2013/9/4 Tom Lane :
> Robert Haas writes:
>> On Wed, Sep 4, 2013 at 10:50 AM, Tom Lane wrote:
>>> Robert Haas writes:
Right. IMHO, this new feature should be similarly simple: when an
unprivileged user references a table, treat that as a reference to a
leakproof view over the tab
2013/9/4 Kevin Grittner :
> Robert Haas wrote:
>> Tom Lane wrote:
>>> Robert Haas writes:
>
IMHO, this new feature should be similarly simple: when an
unprivileged user references a table, treat that as a reference
to a leakproof view over the table, with the RLS qual injected
>>>
2013/9/4 Tom Lane :
> Robert Haas writes:
>> On Wed, Sep 4, 2013 at 10:45 AM, Tom Lane wrote:
>>> Well, the security-barrier view stuff did not present itself as a 100%
>>> solution. But perhaps more to the point, it was conceptually simple to
>>> implement, ie don't flatten views if they have t
Robert Haas writes:
> On Wed, Sep 4, 2013 at 10:45 AM, Tom Lane wrote:
>> Well, the security-barrier view stuff did not present itself as a 100%
>> solution. But perhaps more to the point, it was conceptually simple to
>> implement, ie don't flatten views if they have this bit set, and don't
>>
Robert Haas wrote:
> Tom Lane wrote:
>> Robert Haas writes:
>>> IMHO, this new feature should be similarly simple: when an
>>> unprivileged user references a table, treat that as a reference
>>> to a leakproof view over the table, with the RLS qual injected
>>> into the view.
>>
>> And for inse
* Robert Haas (robertmh...@gmail.com) wrote:
> On Sun, Sep 1, 2013 at 11:47 PM, Greg Smith wrote:
> > And if someone can INSERT values that they can't actually see once they're
> > committed, that's a similarly bad we should describe.
>
> This is desirable in some cases but not others. If the go
Robert Haas writes:
> On Wed, Sep 4, 2013 at 10:50 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> Right. IMHO, this new feature should be similarly simple: when an
>>> unprivileged user references a table, treat that as a reference to a
>>> leakproof view over the table, with the RLS qual injec
On Fri, Aug 30, 2013 at 3:43 PM, Tom Lane wrote:
> I think it's entirely sensible to question whether we should reject (not
> "hold up") RLS if it has major covert-channel problems.
We've already had this argument before, about the security_barrier
view stuff, and that code got committed and is a
2013/9/3 Bruce Momjian :
> On Sun, Sep 1, 2013 at 11:05:58AM -0700, Josh Berkus wrote:
>> > Security community also concludes it is not avoidable nature as long
>> > as human can observe system behavior and estimate something, thus,
>> > security evaluation criteria does not require eliminate cove
On Sun, Sep 1, 2013 at 11:47 PM, Greg Smith wrote:
> And if someone can INSERT values that they can't actually see once they're
> committed, that's a similarly bad we should describe.
This is desirable in some cases but not others. If the goal is
compartmentalization, then it's sensible to preve
Robert Haas writes:
> On Fri, Aug 30, 2013 at 3:43 PM, Tom Lane wrote:
>> I think it's entirely sensible to question whether we should reject (not
>> "hold up") RLS if it has major covert-channel problems.
> We've already had this argument before, about the security_barrier
> view stuff, and tha
On Wed, Sep 4, 2013 at 10:50 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Sep 4, 2013 at 10:45 AM, Tom Lane wrote:
>>> Well, the security-barrier view stuff did not present itself as a 100%
>>> solution. But perhaps more to the point, it was conceptually simple to
>>> implement, ie don'
On Wed, Sep 4, 2013 at 10:45 AM, Tom Lane wrote:
> Well, the security-barrier view stuff did not present itself as a 100%
> solution. But perhaps more to the point, it was conceptually simple to
> implement, ie don't flatten views if they have this bit set, and don't
> push down quals into such s
2013/9/1 Greg Stark :
> On Sun, Sep 1, 2013 at 8:31 PM, Kohei KaiGai wrote:
>> Or, any other criteria even though?
>>
>> My (current) preference is plan (c: we will be able to fix up *this*
>> cover-channel with reasonable efforts on explain code. probably,
>> we can close it if we don't print fil
On Fri, Aug 30, 2013 at 04:24:06PM -0400, Stephen Frost wrote:
> > The scenario I'm worried about is where somebody says "hey, Postgres has
> > RLS now, I can rely on that to hide my sooper sekrit data from other users
> > in the same database", and later they have a security breach through some
>
On Sun, Sep 1, 2013 at 11:05:58AM -0700, Josh Berkus wrote:
> > Security community also concludes it is not avoidable nature as long
> > as human can observe system behavior and estimate something, thus,
> > security evaluation criteria does not require eliminate covert-channels
> > or does not pa
On 9/1/13 5:54 PM, Greg Stark wrote:
So I think up above Tom is wrong about why it's ok that INSERT leaks
keys when it reports a unique key violation. The reason why it's ok
that there's a covert channel there is that the DBA can avoid that
covert channel by being careful when creating unique con
On Sun, Sep 1, 2013 at 8:31 PM, Kohei KaiGai wrote:
> Or, any other criteria even though?
>
> My (current) preference is plan (c: we will be able to fix up *this*
> cover-channel with reasonable efforts on explain code. probably,
> we can close it if we don't print filtered rows under the sub-quer
2013/9/1 Josh Berkus :
> Kaigai,
>
>>> However, we have yet to talk about taking any such provisions with
>>> Postgres. If we commit this patch, arguably we'll have a row-level
>>> security feature which only protects data from well-behaved users, which
>>> seems counterproductive.
>>>
>> The poin
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> That's an astonishingly weak argument, because the bandwidth you're
> talking about is still very high, as in *hundreds* or *thousands* of
> values per minute.
I agree that, in this specific case, we should do something about it.
> It's one thin
2013/8/31 Stephen Frost :
> KaiGai,
>
> * Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
>> The point we shouldn't forget is information leakage via covert-channel
>> has less grade of threat than leakage via main-channel, because of
>> much less bandwidth.
>
> While true, this argument can't be used to
Kaigai,
>> However, we have yet to talk about taking any such provisions with
>> Postgres. If we commit this patch, arguably we'll have a row-level
>> security feature which only protects data from well-behaved users, which
>> seems counterproductive.
>>
> The point we shouldn't forget is informa
On 9/1/13 9:38 AM, Heikki Linnakangas wrote:
To phrase it differently: We already have RLS. It's shipped as an
extension called Veil. Now please explain what's wrong with that
statement, if anything.
Veil was last updated for 9.1 to work against that version, so the first
thing is that it's tw
On 2013-09-01 16:38:51 +0300, Heikki Linnakangas wrote:
> On 30.08.2013 22:57, Josh Berkus wrote:
> >Right now, the primary tool for doing row filtering for MTA is Veil,
> >which has numerous and well-known limitations. If RLS has fewer
> >limitations, or is easier to deploy, maintain, and/or unde
On 30.08.2013 22:57, Josh Berkus wrote:
Right now, the primary tool for doing row filtering for MTA is Veil,
which has numerous and well-known limitations. If RLS has fewer
limitations, or is easier to deploy, maintain, and/or understand, then
it's a valuable feature for that user base, even if
> I think there is another "covert channel" much more serious than
> constrains. You can gather information about hidden data by reading
> query plans.
I think a lot of people would be quite happy to simply disallow EXPLAIN.
Define a permission for it, grant it to public and newly created
users/g
KaiGai,
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> The point we shouldn't forget is information leakage via covert-channel
> has less grade of threat than leakage via main-channel, because of
> much less bandwidth.
While true, this argument can't be used to simply ignore any and all
covert cha
2013/8/30 Tom Lane :
> Josh Berkus writes:
>> On 08/30/2013 12:43 PM, Tom Lane wrote:
>>> In short, "we can check some check-box" is a really, really bad reason
>>> to accept a security-related feature. If we're going to put up with
>>> all the downsides of RLS, I want the end result to be someth
2013/8/30 Josh Berkus :
> On 08/30/2013 03:05 AM, Kohei KaiGai wrote:
>
>>> Surely someone in the security community has discussed this?
>>>
>> Security community considers covert channel is a hard to solve problem;
>> nearly impossible to eliminate.
>> Let's see the summary in wikipedia:
>> http
Josh Berkus writes:
> On 08/30/2013 12:43 PM, Tom Lane wrote:
>> In short, "we can check some check-box" is a really, really bad reason
>> to accept a security-related feature. If we're going to put up with
>> all the downsides of RLS, I want the end result to be something that's
>> actually secu
* Tom Lane (t...@sss.pgh.pa.us) wrote:
> Stephen Frost writes:
> > We have issues with covert channels even without RLS though and holding
> > up RLS because it doesn't fix all the covert channels isn't sensible.
>
> I think it's entirely sensible to question whether we should reject (not
> "hold
On 08/30/2013 12:43 PM, Tom Lane wrote:
> In short, "we can check some check-box" is a really, really bad reason
> to accept a security-related feature. If we're going to put up with
> all the downsides of RLS, I want the end result to be something that's
> actually secure, not something that give
Stephen Frost writes:
> We have issues with covert channels even without RLS though and holding
> up RLS because it doesn't fix all the covert channels isn't sensible.
I think it's entirely sensible to question whether we should reject (not
"hold up") RLS if it has major covert-channel problems.
Josh,
* Josh Berkus (j...@agliodbs.com) wrote:
> On 08/30/2013 03:05 AM, Kohei KaiGai wrote:
> > Security community considers covert channel is a hard to solve problem;
> > nearly impossible to eliminate.
While impossible to eliminate, we should certainly consider cases like
this where we can do
On 08/30/2013 03:05 AM, Kohei KaiGai wrote:
>> Surely someone in the security community has discussed this?
>>
> Security community considers covert channel is a hard to solve problem;
> nearly impossible to eliminate.
> Let's see the summary in wikipedia:
> http://en.wikipedia.org/wiki/Covert_c
2013/8/29 Tom Lane :
> Josh Berkus writes:
>>> That would close only one covert channel. Others were already pointed out
>>> upthread, and I'll bet there are more ...
>
>> Mind you, fundamentally this is no different from allowing INSERT
>> permission on a table but denying SELECT, or denying SEL
2013/8/29 David Fetter :
> On Thu, Aug 29, 2013 at 10:05:14AM -0400, Tom Lane wrote:
>> Alexander Korotkov writes:
>> > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote:
>> >> It is out of scope for this feature. We usually calls this type
>> >> of information leakage "covert channel"; that is
2013/8/29 Josh Berkus :
> Kaigai,
>
>> Although I didn't touch this task by myself, my senior colleague said that we
>> calculated some possible bandwidth of leakage as an evident when we ship
>> supercomputer system with MAC feature for customer who worry about security.
>> I'm not sure how to mea
On Thu, Aug 29, 2013 at 10:05:14AM -0400, Tom Lane wrote:
> Alexander Korotkov writes:
> > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote:
> >> It is out of scope for this feature. We usually calls this type
> >> of information leakage "covert channel"; that is not avoidable in
> >> principl
Josh Berkus writes:
>> That would close only one covert channel. Others were already pointed out
>> upthread, and I'll bet there are more ...
> Mind you, fundamentally this is no different from allowing INSERT
> permission on a table but denying SELECT, or denying SELECT on certain
> columns. I
>> I'm not sure what the solution would be, exactly. Deny permission for
>> EXPLAIN on certain tables?
>
> That would close only one covert channel. Others were already pointed out
> upthread, and I'll bet there are more ...
Mind you, fundamentally this is no different from allowing INSERT
per
Josh Berkus writes:
> It's one thing to day "we can't solve this covert channel issue right
> now in this patch", but saying "we don't plan to solve it at all" is
> likely to doom the patch.
> I'm not sure what the solution would be, exactly. Deny permission for
> EXPLAIN on certain tables?
Tha
* Kohei KaiGai (kai...@kaigai.gr.jp) wrote:
> Although I didn't touch this task by myself, my senior colleague said that we
> calculated some possible bandwidth of leakage as an evident when we ship
> supercomputer system with MAC feature for customer who worry about security.
> I'm not sure how to
Kaigai,
> Although I didn't touch this task by myself, my senior colleague said that we
> calculated some possible bandwidth of leakage as an evident when we ship
> supercomputer system with MAC feature for customer who worry about security.
> I'm not sure how to measure it. However, if we assume
2013/8/29 k...@rice.edu :
> On Thu, Aug 29, 2013 at 04:14:53PM +0200, Kohei KaiGai wrote:
>> 2013/8/29 Alexander Korotkov :
>> > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote:
>> >>
>> >> 2013/8/28 Oleg Bartunov :
>> >> > btw, there is serious problem with row-level security and constraints.
On Thu, Aug 29, 2013 at 04:14:53PM +0200, Kohei KaiGai wrote:
> 2013/8/29 Alexander Korotkov :
> > On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote:
> >>
> >> 2013/8/28 Oleg Bartunov :
> >> > btw, there is serious problem with row-level security and constraints.
> >> > For
> >> > example, user
2013/8/29 Alexander Korotkov :
> On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote:
>>
>> 2013/8/28 Oleg Bartunov :
>> > btw, there is serious problem with row-level security and constraints.
>> > For
>> > example, user with low security level could use unique constraint to
>> > know
>> > about
Alexander Korotkov writes:
> On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote:
>> It is out of scope for this feature. We usually calls this type of
>> information leakage "covert channel"; that is not avoidable in principle.
> I think there is another "covert channel" much more serious than
On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote:
> 2013/8/28 Oleg Bartunov :
> > btw, there is serious problem with row-level security and constraints.
> For
> > example, user with low security level could use unique constraint to know
> > about existence of a row with higher security. I don
Any constraints could be "covert channel".
On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai wrote:
> 2013/8/28 Oleg Bartunov :
> > btw, there is serious problem with row-level security and constraints.
> For
> > example, user with low security level could use unique constraint to know
> > about ex
2013/8/28 Oleg Bartunov :
> btw, there is serious problem with row-level security and constraints. For
> example, user with low security level could use unique constraint to know
> about existence of a row with higher security. I don't know, what is the
> best practice to avoid this.
>
It is out o
btw, there is serious problem with row-level security and constraints. For
example, user with low security level could use unique constraint to know
about existence of a row with higher security. I don't know, what is the
best practice to avoid this.
On Wed, Aug 28, 2013 at 1:37 AM, Greg Smith
On 7/20/13 10:08 AM, Kohei KaiGai wrote:
Hmm. I didn't have this idea. It seems to me fair enough and kills
necessity to enhance RangeTblEntry and getrelid() indeed.
I try to fix up this implementation according to your suggestion.
How is that going? I'm going to do a serious review of this my
On Tue, Jul 23, 2013 at 11:30:14AM -0700, Josh Berkus wrote:
> Greg,
>
> > It's more than the available experienced reviewers are willing to chew
> > on fully as volunteers. The reward for spending review time is pretty
> > low right now.
>
> Short of paying for review time, I don't think we hav
On 07/23/2013 03:34 PM, Greg Smith wrote:
> I happen to think the review structure is one of the most important
> components to PostgreSQL release quality. It used to be a single level
> review with just the committers, now it's a two level structure. The
> reason the Postgres code is so good is
On 7/23/13 2:30 PM, Josh Berkus wrote:
You know as well as me that, as consultants, we can get clients to pay for 10%
extra time
for review in the course of developing a feature
Before this number gets quoted anywhere, I think it's on the low side.
I've spent a good bit of time measuring how
Greg,
> It's more than the available experienced reviewers are willing to chew
> on fully as volunteers. The reward for spending review time is pretty
> low right now.
Short of paying for review time, I don't think we have another solution
for getting the "big patches" reviewed, except to rely o
On 7/23/13 12:10 PM, Josh Berkus wrote:
Apparently it's a little much for experienced reviewers to chew on, too,
since I've been trying to get someone to review it since the beginning
of the Commitfest.
It's more than the available experienced reviewers are willing to chew
on fully as voluntee
On 07/22/2013 01:27 PM, Greg Smith wrote:
>
> Anyone who would like to see RLS committed should consider how you can
> get resources to support a skilled PostgreSQL reviewer spending time on
> it. (This is a bit much to expect new reviewers to chew on usefully)
> I've been working on that here, b
> (This is a bit much to expect new reviewers to chew on usefully) I've been
> working on that here, but I don't have anything I can publicly commit to
> yet.
>
True that.
I spent some time on it, but couldn't come up with anything useful.
Mike's extensive testing seems good enough for me, thoug
On 7/20/13 10:08 AM, Kohei KaiGai wrote:
With that change to expand_targetlist(), the change to getrelid() may
be unnecessary, and then also the new rowsec_relid field in
RangeTblEntry may not be needed.
Hmm. I didn't have this idea. It seems to me fair enough and kills
necessity to enhance Ra
2013/7/19 Dean Rasheed :
> On 19 July 2013 04:09, Greg Smith wrote:
>> On 7/18/13 11:03 PM, Stephen Frost wrote:
>>>
>>> Wasn't there a wiki page about this
>>> feature which might also help? Bigger question- is it correct for the
>>> latest version of the patch?
>>
>>
>> https://wiki.postgresql.
2013/7/19 Stephen Frost :
> * Greg Smith (g...@2ndquadrant.com) wrote:
>> On 7/18/13 7:57 PM, Karol Trzcionka wrote:
>> >Current head 4cbe3ac3e86790d05c569de4585e5075a62a9b41 -> patch applies
>> >correct (only change needed in parallel_schedule).
>> >However it fails on own regression tests (other
Dean Rasheed writes:
> I took a look at this patch too. I didn't read all the code in detail,
> but there was one area I wondered about --- is it still necessary to
> add the new field rowsec_relid to RangeTblEntry?
> As far as I can see, it is only used in the new function getrelid()
> which rep
On 19 July 2013 04:09, Greg Smith wrote:
> On 7/18/13 11:03 PM, Stephen Frost wrote:
>>
>> Wasn't there a wiki page about this
>> feature which might also help? Bigger question- is it correct for the
>> latest version of the patch?
>
>
> https://wiki.postgresql.org/wiki/RLS has accumulated a lot
On 7/18/13 11:03 PM, Stephen Frost wrote:
Wasn't there a wiki page about this
feature which might also help? Bigger question- is it correct for the
latest version of the patch?
https://wiki.postgresql.org/wiki/RLS has accumulated a lot of older
debris that may or may not be useful here.
Thi
* Greg Smith (g...@2ndquadrant.com) wrote:
> On 7/18/13 7:57 PM, Karol Trzcionka wrote:
> >Current head 4cbe3ac3e86790d05c569de4585e5075a62a9b41 -> patch applies
> >correct (only change needed in parallel_schedule).
> >However it fails on own regression tests (other tests pass).
>
> I got a reject
Current head 4cbe3ac3e86790d05c569de4585e5075a62a9b41 -> patch applies
correct (only change needed in parallel_schedule).
However it fails on own regression tests (other tests pass).
Regards,
Karol
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subs
With the current HEAD and v3 patch I'm seeing the following error with
"make check".
--
== creating temporary installation==
== initializing database system ==
pg_regress: initdb failed
Examine /usr/local/src/postgres.patched.v
Hackers,
Please, oh please, won't someone review this? This patch has been 3
years in the making, so I suspect that it will NOT be a fast review.
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes
98 matches
Mail list logo
