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 views.
To
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
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 (mutually
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.
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
On Wed, Nov 6, 2013 at 1:38 AM, Craig Ringer cr...@2ndquadrant.com 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
On Thu, Nov 7, 2013 at 9:08 PM, Craig Ringer cr...@2ndquadrant.com 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
On 6 November 2013 19:12, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2013/11/6 Craig Ringer cr...@2ndquadrant.com:
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
On Wed, Nov 6, 2013 at 6:38 AM, Craig Ringer cr...@2ndquadrant.com 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
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
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
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 SB
On 6 November 2013 09:23, Craig Ringer cr...@2ndquadrant.com 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
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
--
2013/11/6 Craig Ringer cr...@2ndquadrant.com:
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
On Mon, Nov 4, 2013 at 8:46 PM, Craig Ringer cr...@2ndquadrant.com 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
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 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 or
Craig Ringer cr...@2ndquadrant.com 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,
On Mon, Nov 4, 2013 at 9:37 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Craig Ringer cr...@2ndquadrant.com 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
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
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 t...@sss.pgh.pa.us 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
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
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
--
Sent
On Wed, Sep 4, 2013 at 10:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 4, 2013 at 10:45 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Well, the security-barrier view stuff did not present itself as a 100%
solution. But perhaps more to the point, it
Robert Haas robertmh...@gmail.com writes:
On Fri, Aug 30, 2013 at 3:43 PM, Tom Lane t...@sss.pgh.pa.us 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
On Sun, Sep 1, 2013 at 11:47 PM, Greg Smith g...@2ndquadrant.com 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
2013/9/3 Bruce Momjian br...@momjian.us:
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
On Fri, Aug 30, 2013 at 3:43 PM, Tom Lane t...@sss.pgh.pa.us 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 4, 2013 at 10:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Right. IMHO, this new feature should be similarly simple: when an
unprivileged user references a table, treat that as a reference to a
* Robert Haas (robertmh...@gmail.com) wrote:
On Sun, Sep 1, 2013 at 11:47 PM, Greg Smith g...@2ndquadrant.com 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
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com 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
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 4, 2013 at 10:45 AM, Tom Lane t...@sss.pgh.pa.us 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
2013/9/4 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 4, 2013 at 10:45 AM, Tom Lane t...@sss.pgh.pa.us 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
2013/9/1 Greg Stark st...@mit.edu:
On Sun, Sep 1, 2013 at 8:31 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
On Wed, Sep 4, 2013 at 10:45 AM, Tom Lane t...@sss.pgh.pa.us 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
2013/9/4 Kevin Grittner kgri...@ymail.com:
Robert Haas robertmh...@gmail.com wrote:
Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
IMHO, this new feature should be similarly simple: when an
unprivileged user references a table, treat that as a reference
to a
2013/9/4 Tom Lane t...@sss.pgh.pa.us:
Robert Haas robertmh...@gmail.com writes:
On Wed, Sep 4, 2013 at 10:50 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Right. IMHO, this new feature should be similarly simple: when an
unprivileged user references a
On Wed, Sep 4, 2013 at 11:22 AM, Tom Lane t...@sss.pgh.pa.us 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
Kohei KaiGai kai...@kaigai.gr.jp writes:
2013/9/4 Tom Lane t...@sss.pgh.pa.us:
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
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 pay
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
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
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
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
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
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 information
2013/8/31 Stephen Frost sfr...@snowman.net:
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
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 thing
2013/9/1 Josh Berkus j...@agliodbs.com:
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
On Sun, Sep 1, 2013 at 8:31 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
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
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
2013/8/29 Josh Berkus j...@agliodbs.com:
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
2013/8/29 David Fetter da...@fetter.org:
On Thu, Aug 29, 2013 at 10:05:14AM -0400, Tom Lane wrote:
Alexander Korotkov aekorot...@gmail.com writes:
On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It is out of scope for this feature. We usually calls this type
of
2013/8/29 Tom Lane t...@sss.pgh.pa.us:
Josh Berkus j...@agliodbs.com 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
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_channel
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
Stephen Frost sfr...@snowman.net 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
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 gives the
Josh Berkus j...@agliodbs.com 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
* Tom Lane (t...@sss.pgh.pa.us) wrote:
Stephen Frost sfr...@snowman.net 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
2013/8/30 Josh Berkus j...@agliodbs.com:
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:
2013/8/30 Tom Lane t...@sss.pgh.pa.us:
Josh Berkus j...@agliodbs.com 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
Any constraints could be covert channel.
On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2013/8/28 Oleg Bartunov obartu...@gmail.com:
btw, there is serious problem with row-level security and constraints.
For
example, user with low security level could use unique
On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2013/8/28 Oleg Bartunov obartu...@gmail.com:
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
Alexander Korotkov aekorot...@gmail.com writes:
On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai kai...@kaigai.gr.jp 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
2013/8/29 Alexander Korotkov aekorot...@gmail.com:
On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2013/8/28 Oleg Bartunov obartu...@gmail.com:
btw, there is serious problem with row-level security and constraints.
For
example, user with low security level could
On Thu, Aug 29, 2013 at 04:14:53PM +0200, Kohei KaiGai wrote:
2013/8/29 Alexander Korotkov aekorot...@gmail.com:
On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2013/8/28 Oleg Bartunov obartu...@gmail.com:
btw, there is serious problem with row-level security and
2013/8/29 k...@rice.edu k...@rice.edu:
On Thu, Aug 29, 2013 at 04:14:53PM +0200, Kohei KaiGai wrote:
2013/8/29 Alexander Korotkov aekorot...@gmail.com:
On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
2013/8/28 Oleg Bartunov obartu...@gmail.com:
btw, there is
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 a
* 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
Josh Berkus j...@agliodbs.com 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
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
Josh Berkus j...@agliodbs.com 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
On Thu, Aug 29, 2013 at 10:05:14AM -0400, Tom Lane wrote:
Alexander Korotkov aekorot...@gmail.com writes:
On Wed, Aug 28, 2013 at 4:17 PM, Kohei KaiGai kai...@kaigai.gr.jp wrote:
It is out of scope for this feature. We usually calls this type
of information leakage covert channel; that is
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
2013/8/28 Oleg Bartunov obartu...@gmail.com:
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
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
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 have another
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, but I
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
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 on
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
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 isn't
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
(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, though.
2013/7/19 Stephen Frost sfr...@snowman.net:
* 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
2013/7/19 Dean Rasheed dean.a.rash...@gmail.com:
On 19 July 2013 04:09, Greg Smith g...@2ndquadrant.com 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?
On 19 July 2013 04:09, Greg Smith g...@2ndquadrant.com 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
Dean Rasheed dean.a.rash...@gmail.com 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
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
* 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 rejected hunk
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.
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
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
