Re: [HACKERS] 8.4 release planning
I understand Simon is extremely busy on his own patch. I appreciate if anyone help the review. 2009/2/6 Fujii Masao : > Hi, > > On Tue, Feb 3, 2009 at 5:08 AM, Bruce Momjian wrote: >>> o Others >> >> We will focus on all the other items on the commit fest page, and that >> will determine our time-line for 8.4 beta, i.e. the first three items >> will not delay our beta release. > > Simon is assigned as reviewer of PITR performance improvement patch, > but I think that he is too busy with HS to check the code. More reviewer > should be assigned to that? > > Regards, > > -- > Fujii Masao > NIPPON TELEGRAPH AND TELEPHONE CORPORATION > NTT Open Source Software Center > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- -- Koichi Suzuki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Hi, On Tue, Feb 3, 2009 at 5:08 AM, Bruce Momjian wrote: >> o Others > > We will focus on all the other items on the commit fest page, and that > will determine our time-line for 8.4 beta, i.e. the first three items > will not delay our beta release. Simon is assigned as reviewer of PITR performance improvement patch, but I think that he is too busy with HS to check the code. More reviewer should be assigned to that? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
To summarize where I think we are, release-wise: > o Log streaming hold for 8.5 > o Hot standby if committable for 8.4, fine, if not, 8.5, Heikki decides > o SE-PostgreSQL no row-level security, if committable for 8.4, fine, if not, 8.5 > o Others We will focus on all the other items on the commit fest page, and that will determine our time-line for 8.4 beta, i.e. the first three items will not delay our beta release. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
Peter Eisentraut wrote: On Thursday 29 January 2009 11:40:48 Stefan Kaltenbrunner wrote: well from a quick glance there is the bugzilla demo install as well as pieces of reviewboard and patchwork on the trackerdemo jail. So what's the URL and where can we sign up? resurrected the install and subscribed it to pgsql-hackers: http://trackerdemo.postgresql.org however it seems that it won't deal with patches that just have Content-Type: text/plain (like: http://archives.postgresql.org/pgsql-hackers/2009-01/msg02586.php) - seems not to hard to fix from a quick glance at the code however. Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Thursday 29 January 2009 12:03:45 Robert Haas wrote: > I > don't believe that you can speed a project up much by adjusting the > length of the release cycle, but it is *sometimes* possible to speed > up a project by dividing up the work over more people. > This is interesting. We had a problem in 8.3 (and most of the releases before that) of too many patches in the queue at the end of the development cycle. Most everyone agreed that more reviewers/committers would help, but given no way to conjure them up, they realized that wasn't a solution. Instead, we went to a tighter development cycle, with one month of dev and then a commifest. This allowed us to better parralelize both reviews and commits, allowed a number of patches to get bumped through multiple fests with relatively few compliants (after all, the next fest was just a month down the line), keep the patch queue pretty manageable (right up untill the end, when we stopped the cycle), and also delivered us some really big features along the way. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
Stefan Kaltenbrunner píše v čt 29. 01. 2009 v 18:29 +0100: > Peter Eisentraut wrote: > > On Thursday 29 January 2009 11:40:48 Stefan Kaltenbrunner wrote: > >> well from a quick glance there is the bugzilla demo install as well as > >> pieces of reviewboard and patchwork on the trackerdemo jail. > > > > So what's the URL and where can we sign up? > > note the "pieces" part of my mail :-) As far as I recall the patchworks > install somehow collided with the reviewboard one so it was disabled > because Zdenek was still actively using reviewboard. I don't use it at this moment. You can disable reviewboard if you want. Zdenek -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
Josh Berkus writes: > But that's *not* actually how we do things. So you're making my point. Well, the stuff around the wiki status board is pretty new and I don't think anyone feels that it's set in stone yet. The thing we don't want to compromise on, IMHO, is that the long-term record of what's happened is in the mailing list archives and *not* in the internal state of some tool we happen to be using. (One obvious reason for not compromising on that is that we'd be locked into whatever tool we first pick.) But it doesn't really matter whether the tool thinks it has archival state, as long as we can make it link to the archives conveniently. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
Josh, Someone submits patch ticket is created reviewer takes ticket comments submitter takes ticket fixes based on comments review takes ticket approves if reviewer is a committers, he commits. if reviewer isn't he set the ticket to "need final review" tickets that are in that state are reviewed by commiters. Sounds like standard stuff to me. But that's *not* actually how we do things. So you're making my point. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
On Thu, 2009-01-29 at 10:18 -0800, Josh Berkus wrote: > All, > > Thing is, our review/commit process is so peculiar to our project that > using *any* prebuilt solution would require us to change our process to > support the tool. And I can't imagine this group doing that. I am not sure I agree with this. Someone submits patch ticket is created reviewer takes ticket comments submitter takes ticket fixes based on comments review takes ticket approves if reviewer is a committers, he commits. if reviewer isn't he set the ticket to "need final review" tickets that are in that state are reviewed by commiters. Sounds like standard stuff to me. Joshua D. Drake > > --Josh > -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
All, Thing is, our review/commit process is so peculiar to our project that using *any* prebuilt solution would require us to change our process to support the tool. And I can't imagine this group doing that. --Josh -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
Peter Eisentraut wrote: On Thursday 29 January 2009 11:40:48 Stefan Kaltenbrunner wrote: well from a quick glance there is the bugzilla demo install as well as pieces of reviewboard and patchwork on the trackerdemo jail. So what's the URL and where can we sign up? note the "pieces" part of my mail :-) As far as I recall the patchworks install somehow collided with the reviewboard one so it was disabled because Zdenek was still actively using reviewboard. Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
> I wish we could get rid of the whole concept and stigma of being "bumped" your > patch will be released in the next release after it's committed. What does it > matter if there's been another release since you started or not? It matters because the intervening beta/release cycle is likely to sap some focus from the ongoing process of patch review. If nothing else, it's a longer period of time before the patch gets another look, and authors, reviewers, and committers have moved on to other things and forgotten details that then need to be rehashed. If we could have commitfests every two months regardless of the release schedule, then I think the timing of releases really wouldn't matter as much. But then we'd need multiple branches and I don't think Tom et. al. want to go that route. And I understand why. Merging in CVS is the suck, but even if you can make that aspect of things easier, it's still going to be some work, and you still have the problem that people might not do enough testing on release N if they're already in the midst of heavy development for release N+1. Linux solves this problem by having back-branch maintainers and subsystem maintainers who have roles that are intermediate between random patch submitter and full committer. We don't really have quite that much structure, maybe because we're a small project. But it's worth thinking about, because if Tom or Peter or Alvaro or Heikki called me up and said, "If you agree to do be responsible for task X over the next year, which I estimate will save me 40 hours of work, I will agree to spend an additional 10 hours over that same time period reviewing and potentially committing your patches" - I would probably take that deal. And if I didn't, I bet there are at least five other people who would be more than happy to get in line. Of course, making that work depends on one of those people having a well-defined task that they trust me (or whoever) to do and that can be severed from the rest of their work, and there may not be anything of that nature (or maybe it's at a higher increment, like 200 hours for 50 hours, in which case it would be more than I could take on, but someone else might be interested). But I think that's what we have to look for. I don't believe that you can speed a project up much by adjusting the length of the release cycle, but it is *sometimes* possible to speed up a project by dividing up the work over more people. > I would still like an answer to my question about what steps there are that > take so many months for a release, but I expect most of them boil down to > (justified) paranoia about testing major features that people haven't already > tested outside of development environments. That I'm not sure about. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Thursday 29 January 2009 08:39:48 Gregory Stark wrote: > I wish we could get rid of the whole concept and stigma of being "bumped" > your patch will be released in the next release after it's committed. What > does it matter if there's been another release since you started or not? > This is the whole point. It isn't that there is a stigma to getting bumped; It matters becase missing a release means 12-14 months before your feature will be released, even when it takes far less time than that to complete the work. That 12-14 month delay has real implications on a number of levels for users and developers. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
On Thursday 29 January 2009 11:40:48 Stefan Kaltenbrunner wrote: > well from a quick glance there is the bugzilla demo install as well as > pieces of reviewboard and patchwork on the trackerdemo jail. So what's the URL and where can we sign up? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Robert Haas writes: >> read up-thread, i've already shown that this would not be the case. remember, >> we reduce the pressure from the large, complex patches that bottleneck the >> process, which allows more parralell review/commit. > > I read what you wrote - I just don't believe it. My own experience is > that doing more releases is more work. Yeah, more releases than once a year is kind of crazy. > Also, two commitfests per release means that if you can't get your patch up > to snuff in two iterations, you're bumped. I wish we could get rid of the whole concept and stigma of being "bumped" your patch will be released in the next release after it's committed. What does it matter if there's been another release since you started or not? ISTM there are two ways to make the release step take less time. Either we sacrifice quality or we change the development process so more testing and review happens during development. I see the latter as realistic if we hold off committing (but not reviewing) any major patches submitted after commitfest#1 until the next commitfest#1. That means when it comes time to release there won't be any major changes in it that people haven't had months to experiment with already. I would still like an answer to my question about what steps there are that take so many months for a release, but I expect most of them boil down to (justified) paranoia about testing major features that people haven't already tested outside of development environments. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production Tuning -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
> read up-thread, i've already shown that this would not be the case. remember, > we reduce the pressure from the large, complex patches that bottleneck the > process, which allows more parralell review/commit. I read what you wrote - I just don't believe it. My own experience is that doing more releases is more work. Also, two commitfests per release means that if you can't get your patch up to snuff in two iterations, you're bumped. The diminished pain of being bumped will, I think, be more than balanced out by the increased frequency of bumps. Many patches needed 2 or 3 commitfests to get committed; all of the people who need 3 iterations, and anyone who needs 2 iterations and doesn't submit until the second commitfest of the cycle, will take two releases to get out the door. I don't believe you're ever going to make beta/release so low-impact that that won't be disruptive or irritating to people. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
Magnus Hagander wrote: Stefan Kaltenbrunner wrote: Magnus Hagander wrote: On 29 jan 2009, at 05.35, Bruce Momjian wrote: Peter Eisentraut wrote: On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote: Marko Kreen wrote: On 1/27/09, Peter Eisentraut wrote: On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote: Such app already exists: http://ozlabs.org/~jk/projects/patchwork/ So it's a matter of just setting it up. I was in fact in the process of setting that up just now. :-) Nice to know. :) I feel that even if we decide to do our own solution it would be good to try existing solution first. IIRC, we already installed and tried this a while ago. I don't remember exactly what it failed on, but there was something pretty clear. But maybe it's been fixed by now. Details? I find no public record of this. I think it was Keystone; Marc set it up. Not at all. That was *ages* ago. This was recently, and I was part of setting it up myself... In fact we still have the jail running ... That's reviewboard AFAIK, or do we also have one with patchwork? Which one? well from a quick glance there is the bugzilla demo install as well as pieces of reviewboard and patchwork on the trackerdemo jail. Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
Stefan Kaltenbrunner wrote: > Magnus Hagander wrote: >> >> >> On 29 jan 2009, at 05.35, Bruce Momjian wrote: >> >>> Peter Eisentraut wrote: On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote: > Marko Kreen wrote: >> On 1/27/09, Peter Eisentraut wrote: >>> On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote: Such app already exists: http://ozlabs.org/~jk/projects/patchwork/ So it's a matter of just setting it up. >>> >>> I was in fact in the process of setting that up just now. :-) >> >> Nice to know. :) I feel that even if we decide to do our own >> solution it would be good to try existing solution first. > > IIRC, we already installed and tried this a while ago. I don't > remember > exactly what it failed on, but there was something pretty clear. But > maybe it's been fixed by now. Details? I find no public record of this. >>> >>> I think it was Keystone; Marc set it up. >> >> Not at all. That was *ages* ago. This was recently, and I was part of >> setting it up myself... > > In fact we still have the jail running ... That's reviewboard AFAIK, or do we also have one with patchwork? Which one? //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
Magnus Hagander wrote: On 29 jan 2009, at 05.35, Bruce Momjian wrote: Peter Eisentraut wrote: On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote: Marko Kreen wrote: On 1/27/09, Peter Eisentraut wrote: On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote: Such app already exists: http://ozlabs.org/~jk/projects/patchwork/ So it's a matter of just setting it up. I was in fact in the process of setting that up just now. :-) Nice to know. :) I feel that even if we decide to do our own solution it would be good to try existing solution first. IIRC, we already installed and tried this a while ago. I don't remember exactly what it failed on, but there was something pretty clear. But maybe it's been fixed by now. Details? I find no public record of this. I think it was Keystone; Marc set it up. Not at all. That was *ages* ago. This was recently, and I was part of setting it up myself... In fact we still have the jail running ... Stefan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Wednesday 28 January 2009 23:42:11 Robert Haas wrote: > > Our usual process *is* to try and circumvent our usual process. And I > > believe it will continue to be that way until we lower the incentive to > > lobby for circumvention. > > I think Tom and Bruce have both pretty much stated that they're not > keen on a shorter release cycle, and they're the ones who would have > to do the work, so I think this argument is going nowhere. Moreover, > I agree with them. Having short release cycles would probably be a > good idea if we had a larger community with more patch authors, more > reviewers, and more committers. more reviewers and more committers would actually be an argument against shorter release cycles, since we'd have a better shot at actually getting all patches in in a timely fasion. we dont, and we cant change that. again, thats the whole point of this... look at the variables and see which ones we can and cant change, and if those changes would address the causes. > As it is, I think it would simply > mean that the committers would spend more time doing releases and > back-branch maintenance, and correspondingly less time to do what we > really want them to do: review and commit patches. That problem is > already pretty severe, and it would be a bad thing if it got worse. > read up-thread, i've already shown that this would not be the case. remember, we reduce the pressure from the large, complex patches that bottleneck the process, which allows more parralell review/commit. > If anyone really can't wait a year for a new feature, they can > backport it to the previous release, or pay the patch author to do it. > If they were paying the patch author to develop the feature in the > first place, it shouldn't be a horribly expensive proposition. > i dont think we as a community should encourage people to pay for private releases. that is a *really* bad idea. > At the moment, what we really should be doing is conducting final > reviews of as many patches as possible and trying to make sure that > they are in good shape to be committed so that the people who have put > in hard work for THIS release have a chance to see that work go out > the door in a somewhat timely fashion. > not that i disagree, but if we can improve things for the people working on the next release, well, I think that's a good idea too, and I dont see how doing nothing is going to help. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
KaiGai Kohei wrote: > Bruce Momjian wrote: > > OK, time for me to chime in. > > > > I think the outstanding commit-fest items can be broken down into four > > sections: > > > > o Log streaming > > o Hot standby > > o SE-PostgreSQL > > o Others > > - snip - > > > SE-PostgreSQL has been in steady development for a year so this is the > > time to decide about it. My feeling is if we don't accept it now, we > > are never going to have SE-Linux or row-level security. The next week > > should show us the right direction when we start discussion on > > Wednesday, noon GMT. > > Hmm...? > This conditional punishment of death seems to me not a reasonable one. > If we can found a matter as a result of discussion, which is impossible > to fix within reasonable term, I'll agree it being postponed to v8.5. > However, why is the punishment of death necessary here? What I meant was that this features is not going to get any better than the work you have done, so if we reject it odds are we will never accept it. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
> Our usual process *is* to try and circumvent our usual process. And I believe > it will continue to be that way until we lower the incentive to lobby for > circumvention. I think Tom and Bruce have both pretty much stated that they're not keen on a shorter release cycle, and they're the ones who would have to do the work, so I think this argument is going nowhere. Moreover, I agree with them. Having short release cycles would probably be a good idea if we had a larger community with more patch authors, more reviewers, and more committers. As it is, I think it would simply mean that the committers would spend more time doing releases and back-branch maintenance, and correspondingly less time to do what we really want them to do: review and commit patches. That problem is already pretty severe, and it would be a bad thing if it got worse. If anyone really can't wait a year for a new feature, they can backport it to the previous release, or pay the patch author to do it. If they were paying the patch author to develop the feature in the first place, it shouldn't be a horribly expensive proposition. At the moment, what we really should be doing is conducting final reviews of as many patches as possible and trying to make sure that they are in good shape to be committed so that the people who have put in hard work for THIS release have a chance to see that work go out the door in a somewhat timely fashion. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Robert Treat wrote: On Wednesday 28 January 2009 20:12:40 Bruce Momjian wrote: Robert Treat wrote: The revisionism was that of "remarkable failure". That was our shortest release cycle in the modern era. And it didn't have the advantage of the commitfest process. But I think what is important here is to recognize why it didn't work. Once again we ended up with large, complex features (HOT, tsearch) that people didn't want to wait 14 months to see if they missed the 8.3 release. And yes, most of these same arguements were raised then... "full text search is killer feature", "whole applications are waiting for in-core full text search", "hot will give allow existing customers to use postgres on a whole new level", "not fair to push back patches so long when developers followed the rules", "sponsors wont want to pay for features they wont see for years", "developers dont want to wait so long to see features committed", and on and on... I think the big reminder for me from above is that we will always have big stuff that doesn't make a certain major release, and trying to circumvent our existing process is usually a mistake. Our usual process *is* to try and circumvent our usual process. And I believe it will continue to be that way until we lower the incentive to lobby for circumvention. Anybody lobbying to get the process circumvented gets their feature reverted? :-) cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Wednesday 28 January 2009 20:12:40 Bruce Momjian wrote: > Robert Treat wrote: > > The revisionism was that of "remarkable failure". That was our shortest > > release cycle in the modern era. And it didn't have the advantage of the > > commitfest process. > > > > But I think what is important here is to recognize why it didn't work. > > Once again we ended up with large, complex features (HOT, tsearch) that > > people didn't want to wait 14 months to see if they missed the 8.3 > > release. And yes, most of these same arguements were raised then... "full > > text search is killer feature", "whole applications are waiting for > > in-core full text search", "hot will give allow existing customers to use > > postgres on a whole new level", "not fair to push back patches so long > > when developers followed the rules", "sponsors wont want to pay for > > features they wont see for years", "developers dont want to wait so long > > to see features committed", and on and on... > > I think the big reminder for me from above is that we will always have > big stuff that doesn't make a certain major release, and trying to > circumvent our existing process is usually a mistake. > Our usual process *is* to try and circumvent our usual process. And I believe it will continue to be that way until we lower the incentive to lobby for circumvention. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Gregory Stark wrote: > I'm a bit shocked by how long Tom expects the release cycle to take even if we > froze the code today. I guess I forget how long it takes and how many steps > there are from past releases. If it's going to be 9+ months between Nov 1st > and the first commitfest I'm worried about how many patches will be > languishing in the queue with their authors having moved on to other more > fruitful pastures in the mean time. If we delay further we're talking about > close to a year with developers left hanging. What makes the period long are the many things we don't know are broken in CVS, but we know we will find before the final release. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Robert Treat wrote: > > We are going to have exactly > > no credibility if we tell Simon et al "we're pushing these patches to > > 8.5, but don't worry, it'll be a short release cycle". > > > > The other options being we stall 8.4 indefinatly waiting for HS (which, > honestly I am comfortable with), or his patches get pushed and he doesnt get > them for another 14 months. Seems to me our credibility isn't really even a > factor here. > > Right now I'm really trying to figure out how to solve this problem for the > long term. If we say up front now that the next 2 cycles are short cycles, > then I think people will be more willing to push patches come end-of-8.5 (and > let's not pretend we're not going to have this same argument over streaming > replication or synchronous replay or merge command or whatever hot feature is > almost ready at that time) You want the fix --- have people complete their patches long before the last commit fest --- no matter of adjustment is going to fix that. If they can't complete it early, fine, but don't expect we can reach some ideal development schedule by adjusting things --- sometimes ideal just isn't possible. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Robert Treat wrote: > The revisionism was that of "remarkable failure". That was our shortest > release cycle in the modern era. And it didn't have the advantage of the > commitfest process. > > But I think what is important here is to recognize why it didn't work. Once > again we ended up with large, complex features (HOT, tsearch) that people > didn't want to wait 14 months to see if they missed the 8.3 release. And yes, > most of these same arguements were raised then... "full text search is killer > feature", "whole applications are waiting for in-core full text search", "hot > will give allow existing customers to use postgres on a whole new > level", "not fair to push back patches so long when developers followed the > rules", "sponsors wont want to pay for features they wont see for > years", "developers dont want to wait so long to see features committed", and > on and on... I think the big reminder for me from above is that we will always have big stuff that doesn't make a certain major release, and trying to circumvent our existing process is usually a mistake. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Wed, 2009-01-28 at 17:04 -0500, Tom Lane wrote: > The key committers are overstressed already. Some developers are too. I'm sure there's a way to avoid it being a zero-sum game. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Simon Riggs wrote: > > On Tue, 2009-01-27 at 15:46 -0500, Tom Lane wrote: > > Peter Eisentraut writes: > > > Not to pick on you personally, but this is the kind of review that should > > > have > > > happened six months ago, not during a "why is our development process > > > inadequate" discussion on the eve of beta. > > > > Right now, today, in this thread, is the first time that we've had any > > opportunity to debate the design of SEPostgres with knowledgeable people > > other than KaiGai-san. It would likely be better if we started a new > > thread with a more appropriate title, but I see nothing wrong with > > asking pretty fundamental questions. > > Except that Bruce and I already checked detailed documentation > references on this very topic months ago. Check with Bruce; he was > careful to point those things out to me, so I'm sure he'll do the same > for you. I'm satisfied, on this point. Sure, here is the email: http://archives.postgresql.org/pgsql-hackers/2008-09/msg01750.php -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Peter Eisentraut wrote: > On Tuesday 27 January 2009 16:36:50 Stephen Frost wrote: > > * Peter Eisentraut (pete...@gmx.net) wrote: > > > As one of the earlier reviewers, I think the design is OK, but the way > > > the implementation is presented was not acceptable, and very little has > > > been accomplished in terms of reacting to our comments. For example, > > > where is the SQL row security feature, which should have been designed, > > > implemented, and committed separately, in the opinion of most > > > commentaries. > > > > Eh? Are you thinking of column-level privileges, which was committed > > last week? > > No. The point is we would have preferred to see SQL-level row permissions as a separate patch first; that just didn't happen in this case, and it makes the discussion a little more complex. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Bruce Momjian writes: > Tom Lane wrote: >> As the SEPostgres patch is constructed, the planner could *never* trust >> an FK for optimization since it would have no way to know whether row >> level permissions might be present (perhaps only for some rows) at >> execution time. You could only get back the optimization in builds with >> SEPostgres compiled out. That's pretty nasty, especially for packagers >> who have to decide which build setting will displease fewer users. > I am afraid that SQL-level row permissions would also cause that > problem, and I thought they were enabled by default. (The configure > flag --enable-selinux only controls SE-Linux support.) So they would. However, I've already determined that I'm against row-level permissions of either flavor ;-) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Robert Haas wrote: > > The flaw in that argument is that as you are doing it, the > > de-optimization only happens on queries that actually need the behavior. > > As the SEPostgres patch is constructed, the planner could *never* trust > > an FK for optimization since it would have no way to know whether row > > level permissions might be present (perhaps only for some rows) at > > execution time. You could only get back the optimization in builds with > > SEPostgres compiled out. That's pretty nasty, especially for packagers > > who have to decide which build setting will displease fewer users. > > OK, I think I am starting to understand your concern now. > > My understanding of how the world works is SE-PostgreSQL would always > be compiled in but could be turned off at run-time with a GUC. I know > that the original design called for a compile-time switch, but > everyone hated it and I am pretty sure KaiGai changed it. If he > hasn't, he will. :-) > > There was also talk of having a table-level option to include/exclude > the security ID (I'm not sure if it's currently implemented that way). > Obviously that wouldn't be relevant for row-level MAC (because > presumably you would need/want that turned on for all tables) but it > would be very relevant for row-level DAC (because it's easy, at least > for me, to imagine that you would only turn this on for a subset, > possibly quite a small subset, of your tables where you knew that it > was really needed). > > If, by default, we make sepostgresql disabled, MAC security IDs on > newly created tables off, and DAC security IDs on newly created tables > off, then the pain will be confined to people who explicitly request > sepostgresql or row-level DAC. Yes, if there is concern about row-level security turning off optimizations, some flag would have to be checked so the optimization would be possible for sites not using row-level security; ideally there would be a table-level flag, and I think the current patch implements it that way. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Simon Riggs wrote: > > On Tue, 2009-01-27 at 14:18 -0500, Tom Lane wrote: > > Joshua Brindle writes: > > > Tom Lane wrote: > > >> Right, which is why it's bad for something like a foreign key constraint > > >> to expose the fact that the row does exist after all. > > > > > Once again, this is not an issue for us. > > > > Yes it is an issue > > > The question of whether there is a covert channel is only a small part > > of my complaint here. If it's the judgement of security experts that > > that's an acceptable thing, that's fine, it's their turf. But SQL > > behavior is my turf, and I'm not happy with discarding fundamental > > semantic properties. > > Why did we bother to invite Joshua here if we aren't going to listen to > him? > > Thanks for coming to help Joshua, much appreciated. I agree. This is exactly the type of feedback I was hoping for. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Tom Lane wrote: > Robert Haas writes: > > On Tue, Jan 27, 2009 at 12:52 PM, Tom Lane wrote: > >> Right, but you expect that to be a small and predictable cost, say in > >> the single-digits-percentage range. Plan optimizations that > >> suddenly stop happening can cost you multiple orders of magnitude. > > > Well, look at it another way. If we don't accept row-level security > > into PostgreSQL, then people will have to implement it themselves. In > > fact, I currently have a real application that does exactly this. The > > row-filtering is done, in essence, by having the web application add > > certain conditions to the WHERE clause of certain queries depending on > > which user is making the request. And if those WHERE clauses happen > > to mention columns from table X, then table X won't be a candidate for > > join removal. The only difference is that the logic is in my app > > rather than in the database itself. > > > To put that another way, row-level permissions are just another > > attribute of a table that could potentially affect the query result, > > and the impact of referring to that attribute will be exactly the same > > as the impact of referring to any other attribute in that table. > > The flaw in that argument is that as you are doing it, the > de-optimization only happens on queries that actually need the behavior. > As the SEPostgres patch is constructed, the planner could *never* trust > an FK for optimization since it would have no way to know whether row > level permissions might be present (perhaps only for some rows) at > execution time. You could only get back the optimization in builds with > SEPostgres compiled out. That's pretty nasty, especially for packagers > who have to decide which build setting will displease fewer users. I am afraid that SQL-level row permissions would also cause that problem, and I thought they were enabled by default. (The configure flag --enable-selinux only controls SE-Linux support.) -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Wednesday 28 January 2009 12:35:42 Tom Lane wrote: > Robert Treat writes: > > On Wednesday 28 January 2009 08:55:56 Magnus Hagander wrote: > >> We're still going to have to pay the full cost of doing a release every > >> time. With beta/rc management, release notes, announcements, postings, > >> packaging and all those things. > > > > As I pointed out to Tom, by percentage the additional beta/release cycles > > wouldn't be very different than what we have now; the more churn you have > > during development, the longer it takes to beta/release. > > I don't believe that thesis in itself, because it ignores economies of > scale and parallelism for beta testing. And in any case it's complete > nonsense in respect to back-branch maintenance costs. If we double > the frequency of releases we are going to be pretty much forced to halve > the support lifetime, and ain't nobody going to be happy with us. > Yes, back branch maintanance is an issue, but I'd bet that as long as we occasionally designate specific releases as long term support releases (my guess is 1 every 4 releases, though I haven't done the math), people would be comfortable with this. We've already had short maintainance windows for win32 support, and that has gone over without significant uproar. Also other projects (some much larger than ours) have implemented similar schemes, and it's been fairly well recieved. People understand the trade-offs of new features verses stability, and as long as you give them a long term option, they're happy. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
> I considered pg_upgrade one of the "others" on the list; it is not as > complex as the previous three. LOL. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Zdenek Kotala wrote: > > Bruce Momjian p??e v po 26. 01. 2009 v 23:02 -0500: > > OK, time for me to chime in. > > > > I think the outstanding commit-fest items can be broken down into four > > sections: > > > > o Log streaming > > o Hot standby > > o SE-PostgreSQL > > o Others > > You omit pg_upgrade. Does it mean that this project is already killed > for 8.4? I considered pg_upgrade one of the "others" on the list; it is not as complex as the previous three. -- Bruce Momjian http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Dimitri Fontaine writes: > Le 28 janv. 09 à 16:22, Simon Riggs a écrit : >> The only way to keep the dev window open longer is to overlap the >> start of the next cycle with the previous one. i.e. branch new version >> before final release. > This is the second time the idea is raised and I like it. > Do we have anywhere near enough resources for this to happen? No. The key committers are overstressed already. It would also pretty much guarantee that we get *no* help during review and beta, because everyone else will find it more interesting/fun to work on new patches instead. The current system at least gives non-committer developers some motivation to help with that stuff, because they know their patches won't be looked at until beta is over. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Le 28 janv. 09 à 16:22, Simon Riggs a écrit : The only way to keep the dev window open longer is to overlap the start of the next cycle with the previous one. i.e. branch new version before final release. This is the second time the idea is raised and I like it. Do we have anywhere near enough resources for this to happen? That would mean first 8.5 commit-fest begins e.g. April 1st, while hopefully 8.4 enters beta or get ready for it. If no commiter is available for reviewed patch they just get postponed as ready to commit on next commit fest. This way our Round Robin Reviewers team is still at work while in beta, and more importantly developpers still get feedback. -- dim -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Robert Treat writes: > On Wednesday 28 January 2009 08:55:56 Magnus Hagander wrote: >> We're still going to have to pay the full cost of doing a release every >> time. With beta/rc management, release notes, announcements, postings, >> packaging and all those things. > As I pointed out to Tom, by percentage the additional beta/release cycles > wouldn't be very different than what we have now; the more churn you have > during development, the longer it takes to beta/release. I don't believe that thesis in itself, because it ignores economies of scale and parallelism for beta testing. And in any case it's complete nonsense in respect to back-branch maintenance costs. If we double the frequency of releases we are going to be pretty much forced to halve the support lifetime, and ain't nobody going to be happy with us. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Wednesday 28 January 2009 08:55:56 Magnus Hagander wrote: > We're still going to have to pay the full cost of doing a release every > time. With beta/rc management, release notes, announcements, postings, > packaging and all those things. > As I pointed out to Tom, by percentage the additional beta/release cycles wouldn't be very different than what we have now; the more churn you have during development, the longer it takes to beta/release. I'm pretty sure that if we had pushed everything not committed on December 1st, we would be very close to release right now, and that's with more dev cycles than I'm talking about for 8.5. And I think most people (aka not the patch authors :-) would have been willing to push the stuff we're dealing with now if they knew the next release would be closer to 6 months than 14 months. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Wed, 2009-01-28 at 14:55 +0100, Magnus Hagander wrote: > If the release is pushed back, maybe some other patch could also have > been finished by the new deadline - should that also be included? What > about a completely new feature that isn't even started yet, but that > could easily be finished before the new deadline? What makes those less > worthy? Committers have always added features after freeze... For example, Virtual TransactionIds were added to 8.3 almost exactly 5 months after feature freeze. Not even suggested until about 5 months after, in fact. I argued against such a change late in the cycle, but we did it. It's a great feature and I'm glad we did. If we try to shorten the release cycle, we just end up missing out on tuning opportunities that emerge in beta. IIRC 8.2 was delayed while we changed index cost models. Thankfully. 8.0 was shipped with a completely ineffective bgwriter, so the above changes seem like common sense in comparison. The only way to keep the dev window open longer is to overlap the start of the next cycle with the previous one. i.e. branch new version before final release. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Wed, Jan 28, 2009 at 11:31:25AM +0900, KaiGai Kohei wrote: > As I noted before, there is a symmetrical structure between > OS and DBMS. Well, you said that before. I think your analogy is awful. I don't think the similarities are nearly as great as you think, and I also think there are significant differences that _make_ the difference in these cases. In particular, > In operating system, a process accesses objects (like file, > socket, ...) managed by operating system via system calls. > Its security system (filesystem permission, SELinux, ...) > acquires the request and applies its access control rules. > > In DBMS, a client accesses database objects managed by DBMS > via SQL queries. Its security system (Database ACL, > SE-PostgreSQL, ...) aquires the request and applies its access > control rules. the difference here is that in the OS, a process accessing the object has few to no guarantees about concurrency. In RDBMS, a very significant reason even to use the DBMS is the ACID guarantees, which make a number of claims about concurrency that simply aren't there in most filesystems. It's at exactly this architectural point that most of the in-principle design questions have been aimed. My personal view is that those questions haven't really been answered very well, but as I've already said I mostly stopped paying attention to this work several months ago; so maybe I overlooked something. I note that Peter and Bruce seem to have been satisfied, so maybe they understood something I don't (that's quite likely). > The most significant feature is centralized access control policy > between OS and DBMS. Right, I get that; but all the discussion I've seen on this suggest that, to get the benefit of the centralised access control, I trade away certain well-understood assumptions of a relational environment, but without much indication that I've done so. > I talked here we should consider the value of information asset > is independent from the way to store them. Yes, I know that was your premise. I am not entirely sure I agree with it, is the thing. > Needless to say, the value of information asset is decided by its > contents. Nonsense. The value of an information asset is determined only partly by its contents. I'd argue that the value of an information asset is a function of its use-value. If the information asset is completely unusable, then it isn't worth anything at all. > If your credit card number is recorded on a paper, > do you think it has lesser value than recorded on database? Yes. The database makes the credit card number available to other applications, which can then use that data to charge the credit card with other purchases. For me, therefore, the piece of paper, correctly handled, imposes less risk than the database; in addition, the piece of paper offers a smaller advantage, because it cannot be leveraged to make other interactions more convenient. Finally, the piece of paper offers a different kind of risk, because if it is mishandled and then becomes the basis on which the number ends up in a database, I have a new problem for which I was not prepared. I believe my fundamental objection was that, as far as I was able to tell, SELinux simply didn't have anything useful to say about concurrent actions on data under SE controls; that's because it was aimed at a fairly primitive database (a filesystem) without the rich concurrency support of RDBMS. I still don't see anywhere in your discussions an extension of the SELinux model to account for that concurrency richness, so I think there's something wrong with the principles from which your're starting. I'm totally prepared to admit I've missed something, however. Also, since this isn't really my problem any more, I'm unlikely to spend much time reading more design notes or anything of the sort. Finally, > It finally enables to apply centralized access control policy on > whole of application stack. > Please note that 95% of attacks in 2008 targeted to web system, > so it gives a nightmare for security folks. this argument gets to the heart of what you seem to want, which is a centralized system that guarantees the controls you want. I'm actually dubious that such centralization is actually the benefit that its proponents seem to think it is; but if it is, then the centralised system needs to be exactly as rich as the richest system under control. By starting with SELinux, I argue that the approach starts with a too-poor model. (See above.) More fundamentally, the premise that the database is just a part of an "application stack" is, in my view, exactly _why_ these systems are so vulnerable to attack. Database management systems are not designed to be dumb storage for a single application, and they're actually very poorly adapted to such a role. My impression is that SEPostgres is an attempt to finally force the database system under such controls, as though it were a glorified filesystem. I hav
Re: [HACKERS] 8.4 release planning
Magnus Hagander writes: > Josh Berkus wrote: >> >> One client is planning on deploying a rather complex FS cloning >> infrastructure just to have a bunch of reporting, testing and read-only >> search databases they need. They'd be thrilled with an HS feature which >> produced DBs which were an hour out of date (or even 6 hours out of >> date), but ran read-only queries. > > I have a lot of clients who would be thrilled to have stuff that's been > in our tree for half a year by now, and they'd be thrilled to have it > *now*. How much extra should we have them wait for the needs of your > clients? I really am unconvinced by the argument that delaying existing features is a big deal. Logically it's less of a big deal than delaying HS a whole release cycle which I already said I think isn't a big deal either. This is purely a question of latency between development and release; we still get just as much in each release, it's just 6-12 months later than it might have been. What bothers me is delaying work on things like Bitmap Indexes which won't really start in earnest until Gianni can get feedback from the lists after the release. Or Join Removal which Simon isn't going to look at until after HS is committed (not *released* -- once it's *committed* he'll be free to go on to other things). This would impact *bandwidth* of development which I think is a much bigger deal. It reduces the amount of new features in each release, not just which release they fall in. I'm a bit shocked by how long Tom expects the release cycle to take even if we froze the code today. I guess I forget how long it takes and how many steps there are from past releases. If it's going to be 9+ months between Nov 1st and the first commitfest I'm worried about how many patches will be languishing in the queue with their authors having moved on to other more fruitful pastures in the mean time. If we delay further we're talking about close to a year with developers left hanging. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Robert Haas wrote: >> I think the best thing we could do overall is to set release dates and >> stick to them. If your patch is not ready, well, at least it will get >> out in a defined amount of time. Right now, the *real* problem with it >> being pushed to the next release is you don't know how successful some >> other guy will be at persuading us to delay the next release. > > +1, LOL. > > Let's not forget that we've already got CTE, window functions, partial > vacuums, and column-level permissions, all of which are major features > that should benefit a lot of people. I hope Hot Standby gets > committed but even if it doesn't, I'm still going to get a lot of > benefit out of this release, so I'd like it to happen on some sort of > reasonable time scale. Agreed. Even without HS, this will be one of the biggest releases we've had in a while, IMHO. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Josh Berkus wrote: > >> That's modest. I've talked to several oracle and db2 shops that want a >> standby for reporting that has relatively easy setup/maintenance >> (handling ddl is a big part of this) and the HS feature your working >> on will give them something as good as what they are getting now. So >> yeah, HS appeals to future users as well. > > I've talked to some of my clients, and while they *want* synch or > near-synch HS, even slow HS is useful to them *now*. > > One client is planning on deploying a rather complex FS cloning > infrastructure just to have a bunch of reporting, testing and read-only > search databases they need. They'd be thrilled with an HS feature which > produced DBs which were an hour out of date (or even 6 hours out of > date), but ran read-only queries. I have a lot of clients who would be thrilled to have stuff that's been in our tree for half a year by now, and they'd be thrilled to have it *now*. How much extra should we have them wait for the needs of your clients? (Yes, I have clients now who would very much like HS as well, of course, but that's not the point) //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Robert Treat wrote: > The problem is that the pain point is extremely high for missing a given > release cycle. If you don't make a specific release, you have a 12-14 month > wait for feature arrival. Given that choice, someone who deperately need (aka > wants) HS/SEPostgres/Win32/HOT/IPU/etc... will likely be willing to push a > release 3-6 months for that one feature. There will always be some features that people are willing to push a release for, if it's a feature they want. At least I hope so - because that means we keep adding new features that people want. But as long as there is some overlap in development timelines - which there will *always* be - there will always be some patch that is not quite ready on time. If the release is pushed back, maybe some other patch could also have been finished by the new deadline - should that also be included? What about a completely new feature that isn't even started yet, but that could easily be finished before the new deadline? What makes those less worthy? The question is, how long do we make people wait for *other* features. It delays this version *and* the next. > Incidentally, this is probably why people didnt worry about making a given > commitfest. The pain point was low, so there was no percieved need to rework > a patch for a specific commit, since there was another one just a couple > months away. However, we still see a rush of patches at the final freeze > because people know that "there is no tommorrow" at that point. A problem at this point is that we are basically serializing the project over one or a couple of patches. All those people who aren't qualified to review/work on HS or SEPG are left in a position where they can't get anything done. Sure, they can work on patches offline, and add them to a hypothetical future commitfest that they have no clue when it's going to happen, so they don't know when they need to be available to deal with feedback. And we're back to ending up with a lot of conflicting patches simply because they sit in the queue for too long. That's a lot of developer talent wasted. The commitfests were designed in part to get around this - to get developers quick feedback so they can get on with more features. The final commitfest being much longer than the others by design already makes this hard. Dragging it out even longer makes it an even bigger failure in this way. We can't just say that everybody should help with these patches. Not everybody is qualified to do so, or has an interest to, while they're still both qualified and interested in working on other things for 8.5. >> In the third >> place, unless we get an upgrade-in-place process that works all the >> time, we would be looking at maintaining twice as many back branches >> in order to provide the same kind of release lifespan we have today. >> We are at the limit of what we can realistically do in back-branch >> maintenance already :-( >> > > Yeah, I can't argue with that. I'm not sure it's an unsolvable problem > though; > if odd/even release maintenance doesn't sound good, we could do something > like ubuntus LTS, where we pick 1 release every 3 years to make a long-term > support commitment (I think 5 years is our current max), and keep other > releases on a shorter lifespan (1 or 2 years). Certainly having IPU (or is > that UIP?) would make that an easier decision. We're still going to have to pay the full cost of doing a release every time. With beta/rc management, release notes, announcements, postings, packaging and all those things. The PostgreSQL tree tends to be a lot more stable than others. In many cases, you can just snapshot CVS HEAD and get more or less the same things. Perhaps if someone were to simply maintain a bunch of tags or branches against "known feature-points in the system" in a separate SCM somewhere that'd be enough for people who desperately need the features - or who just want to test them out earlier. That would be close to zero cost for the core project to maintain. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Wed, Jan 28, 2009 at 4:28 AM, Peter Eisentraut wrote: > Greg Smith wrote: > >> PostgreSQL advocacy point, one of the questions Tom asked about a bit >> upthread is still a bit hazy here. There are commercial database offerings >> selling into the "trusted" space already. While the use-cases you describe >> make perfect sense, I don't think it's clear to everyone yet if there's a >> unique draw to a PostgreSQL + selinux solution that the class of customers >> you're talking about would prefer it to purchasing one of those products. >> Is the cost savings the main driver here, or is there something else about >> a secure LAPP stack that makes it particularly compelling? >> > > According to the data available to me, it is a combination of doing it > better than the other guys (e.g., a SELinux type interface instead of > something handcrafted) and the usual cost savings. > I don't know about better, but I would definitely say that it's a more integrated (with the OS) solution. Can you get Oracle to use SELinux policies? Sure. But it would take a combination of Label Security, Fine Grained Access Control tweaks, custom C functions, and custom policies to handle the access control. And, it would cost a helluva lot of money. In short, this would make Postgres quite a bit more appetizing to those who need this functionality, those who prefer SELinux-based policies, and those who don't have the time/money to do it in systems like Oracle. How many people is that? Based on my consulting experience and questions from DoD/DoE people specifically, I think the number of people needing this feature is fairly small right now. But, it wouldn't hurt us to have it. Just to make it clear, this feature wouldn't make Postgres a "trusted" database in any certification sense. So, using that term would likely cause confusion and get people who used it thinking it had an EAL certification into trouble. -- Jonah H. Harris, Senior DBA myYearbook.com
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Magnus Hagander a écrit : > Peter Eisentraut wrote: >> On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote: >>> Marko Kreen wrote: On 1/27/09, Peter Eisentraut wrote: > On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote: > > Such app already exists: > > > > http://ozlabs.org/~jk/projects/patchwork/ > > > > So it's a matter of just setting it up. > > I was in fact in the process of setting that up just now. :-) Nice to know. :) I feel that even if we decide to do our own solution it would be good to try existing solution first. >>> IIRC, we already installed and tried this a while ago. I don't remember >>> exactly what it failed on, but there was something pretty clear. But >>> maybe it's been fixed by now. >> Details? I find no public record of this. > > I don't recall specifically :-( Which in itself might mean it's > worthwhile to make another try. But i recall trying that one and > reviewboard, and none of them was what we needed. > > If you look at Berkus' list of required features (if you haven't seen > it, I'm sure he'll be happy to send you a copy), Josh, can you please give the link to this list of feature ? > you will see that it > doesn't come close. We can always argue if his list is reasonable :-), > but that's just a fact. It has nothing about round-robin reviewers. It > has no keep-track-of-nagging features. It has no integration with our > mail archives. At least it didn't then - it also appears to have no > online documentation, so I can't easily check now :-P > > //Magnus > > - -- Cédric Villemain Administrateur de Base de Données Cel: +33 (0)6 74 15 56 53 http://dalibo.com - http://dalibo.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmAOAMACgkQo/dppWjpEvxn6ACg2F5to39Q9fW9vvm25E9fW2Zl GAAAoOP9yMO3WuT5Rj98s7OyHhDYK4Ui =rP62 -END PGP SIGNATURE- -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
Peter Eisentraut wrote: > On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote: >> Marko Kreen wrote: >>> On 1/27/09, Peter Eisentraut wrote: On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote: > Such app already exists: > > http://ozlabs.org/~jk/projects/patchwork/ > > So it's a matter of just setting it up. I was in fact in the process of setting that up just now. :-) >>> Nice to know. :) I feel that even if we decide to do our own >>> solution it would be good to try existing solution first. >> IIRC, we already installed and tried this a while ago. I don't remember >> exactly what it failed on, but there was something pretty clear. But >> maybe it's been fixed by now. > > Details? I find no public record of this. I don't recall specifically :-( Which in itself might mean it's worthwhile to make another try. But i recall trying that one and reviewboard, and none of them was what we needed. If you look at Berkus' list of required features (if you haven't seen it, I'm sure he'll be happy to send you a copy), you will see that it doesn't come close. We can always argue if his list is reasonable :-), but that's just a fact. It has nothing about round-robin reviewers. It has no keep-track-of-nagging features. It has no integration with our mail archives. At least it didn't then - it also appears to have no online documentation, so I can't easily check now :-P //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Richard Huxton wrote: Greg Smith wrote: Where I suspect this is all is going to settle down into is that if 1) the SE GUC is on and 2) one of the tables in a join has rows filtered, then you can expect that a) it's possible that the result will leak information, which certainly need to be documented, As far as I can tell this is the case however you hide the information. If you implemented it with views you'll have the same issue. If you hide the existence of project p_id="TOPSECRET01" and people can run inserts then they can spot it. Likewise, it you have fkey references to the row then deletions can be used to spot it. It is a covert channel discussion. At least, SE-PostgreSQL does not care about hiding its existence, so it does not prevent user to infer the existence of a tuple with same key value, using PK confliction. (Please note that he must have a info about PK value or lucky to make a key confliction.) But, it enables to prevent unclassified user to read the tuple, and him to know an info the tuple contains "p_id=TOPSECRET01" as a result of this read action. Thanks, -- KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Greg Smith wrote: PostgreSQL advocacy point, one of the questions Tom asked about a bit upthread is still a bit hazy here. There are commercial database offerings selling into the "trusted" space already. While the use-cases you describe make perfect sense, I don't think it's clear to everyone yet if there's a unique draw to a PostgreSQL + selinux solution that the class of customers you're talking about would prefer it to purchasing one of those products. Is the cost savings the main driver here, or is there something else about a secure LAPP stack that makes it particularly compelling? According to the data available to me, it is a combination of doing it better than the other guys (e.g., a SELinux type interface instead of something handcrafted) and the usual cost savings. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Greg Smith wrote: > Where I suspect this is all is going to settle down into is that if 1) > the SE GUC is on and 2) one of the tables in a join has rows filtered, > then you can expect that a) it's possible that the result will leak > information, which certainly need to be documented, As far as I can tell this is the case however you hide the information. If you implemented it with views you'll have the same issue. If you hide the existence of project p_id="TOPSECRET01" and people can run inserts then they can spot it. Likewise, it you have fkey references to the row then deletions can be used to spot it. -- Richard Huxton Archonet Ltd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
On Tuesday 27 January 2009 23:59:46 Magnus Hagander wrote: > Marko Kreen wrote: > > On 1/27/09, Peter Eisentraut wrote: > >> On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote: > >> > Such app already exists: > >> > > >> > http://ozlabs.org/~jk/projects/patchwork/ > >> > > >> > So it's a matter of just setting it up. > >> > >> I was in fact in the process of setting that up just now. :-) > > > > Nice to know. :) I feel that even if we decide to do our own > > solution it would be good to try existing solution first. > > IIRC, we already installed and tried this a while ago. I don't remember > exactly what it failed on, but there was something pretty clear. But > maybe it's been fixed by now. Details? I find no public record of this. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Tuesday 27 January 2009 21:07:48 Tom Lane wrote: > Robert Treat writes: > > The more I think about it, the more I feel that where we failed for 8.3 > > was not having a short 8.4 cycle lined up, which would give more freedom > > to bump patches to the next release. > > Heh. The reason we wanted a short 8.3 cycle was so we could push out > patches that had been held over from 8.2. And the reason that didn't work was because when we got to feature freeze, we once again had several large, complex patches which people didn't want to push for the long 8.4 cycle. (But note: people are willing to push patches when they believe the wait time won't be excessive for eventual inclusion) > We are going to have exactly > no credibility if we tell Simon et al "we're pushing these patches to > 8.5, but don't worry, it'll be a short release cycle". > The other options being we stall 8.4 indefinatly waiting for HS (which, honestly I am comfortable with), or his patches get pushed and he doesnt get them for another 14 months. Seems to me our credibility isn't really even a factor here. Right now I'm really trying to figure out how to solve this problem for the long term. If we say up front now that the next 2 cycles are short cycles, then I think people will be more willing to push patches come end-of-8.5 (and let's not pretend we're not going to have this same argument over streaming replication or synchronous replay or merge command or whatever hot feature is almost ready at that time) > I think the best thing we could do overall is to set release dates and > stick to them. If your patch is not ready, well, at least it will get > out in a defined amount of time. Right now, the *real* problem with it > being pushed to the next release is you don't know how successful some > other guy will be at persuading us to delay the next release. > I wont argue that setting release dates and sticking to them is a bad idea, but that extra month at the end that that occures due to feature lobbying doesn't strike me as the straw breaking the camels back, it's the 12-14 months in front of that people don't want to wait through. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Greg Smith wrote: Where I suspect this is all is going to settle down into is that if 1) the SE GUC is on and 2) one of the tables in a join has rows filtered, then you can expect that a) it's possible that the result will leak information, which certainly need to be documented, and b) the optimizations Tom mentioned that "assume foreign key constraints hold" will not be possible to implement, so performance will suck compared to a similar situation in an unsecured environment. c) security feature gives the optimizer a hint "don't optimize out this table, please!" via a security hook. I think it is a quite reasonable approach, as I noted in another message. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Jaime Casanova wrote: On Tue, Jan 27, 2009 at 2:18 PM, Tom Lane wrote: This seems to me to be exactly parallel to deciding that SELinux should control only table/column permissions within SQL; an approach that would be enormously less controversial, less expensive, and more reliable than what SEPostgres tries to do. seems that the controversial part of sepgsql is row level permissions, can we try to commit (obviously with good revision and test) the table/column privileges part of that patch? Actually, it is already done. http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/utils/misc/guc.c#1242 http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/security/sepgsql/permissions.c#518 Its original purpose is different, to reduce storage consumption. But it can be a point of compromise. See, http://archives.postgresql.org/message-id/492691a8.8030...@ak.jp.nec.com Is it a reasonable option to allow users to turn on/off? I can add a documentation about its background and tradeoffs, for user's correct decision. Thanks, that is still a step on the direction of full centralized security management on the system... let the row level privileges part for 8.5, that way the patch will be smaller now and then... remember, postponed is not rejected is just a way to give more time to think (WITH patch comes from the prior release cycle and was committed in this release), not to think about one scenario but about all possible scenarios in a more wide audience -- OSS Platform Development Division, NEC KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Tom Lane wrote: > The flaw in that argument is that as you are doing it, the > de-optimization only happens on queries that actually need the behavior. > As the SEPostgres patch is constructed, the planner could *never* trust > an FK for optimization since it would have no way to know whether row > level permissions might be present (perhaps only for some rows) at > execution time. Is the "never" is really correct? In the following case, it is necessary not to apply optimization: - SE-PostgreSQL is working, and its row-level access controls are available (sepostgresql_row_level=on). - Row-level ACL is available on the target relation. It is controlable via table option. So, it is necessary to add a new security hook to give a hint the optimizer. Sorry, I overlooked this optimization. But is is not a fundamental design issue. PGACE already has a hook to give a hint to optimizer. It will be a similar one. See, pgaceAllowFunctionInlined(...); http://code.google.com/p/sepgsql/source/browse/trunk/sepgsql/src/backend/security/pgaceHooks.c#948 Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Wed, 28 Jan 2009, KaiGai Kohei wrote: It shows a fact that not negligible number of users accept row-level granularity, even if it has covert channels. From my read of the examples that Chad provided, keeping the existence of things secret from complete outsiders doesn't look like the prime concern. There's plenty of these applications floating around where everyone involved is cleared, but to different levels and projects. The person working on a "secret" project knows perfectly well that there are also "top secret" projects floating around they aren't cleared for, and that's OK. They'll probably detect their existence by the doors they're not allowed through long before they notice that database rows are missing. If you're able to sit in front of a computer that's capable of even reaching this information but aren't supposed to be anywhere near it, that means there's been a physical security breach. Where I suspect this is all is going to settle down into is that if 1) the SE GUC is on and 2) one of the tables in a join has rows filtered, then you can expect that a) it's possible that the result will leak information, which certainly need to be documented, and b) the optimizations Tom mentioned that "assume foreign key constraints hold" will not be possible to implement, so performance will suck compared to a similar situation in an unsecured environment. And all that may very well be just fine as far as the people wanting to build applications with SEPostgreSQL are concerned. It will just hint toward using a schema design with table-level controls instead if you care about high performance on that style of join. -- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Tue, Jan 27, 2009 at 2:18 PM, Tom Lane wrote: > > This seems to me to be exactly parallel to deciding that SELinux should > control only table/column permissions within SQL; an approach that would > be enormously less controversial, less expensive, and more reliable than > what SEPostgres tries to do. > seems that the controversial part of sepgsql is row level permissions, can we try to commit (obviously with good revision and test) the table/column privileges part of that patch? that is still a step on the direction of full centralized security management on the system... let the row level privileges part for 8.5, that way the patch will be smaller now and then... remember, postponed is not rejected is just a way to give more time to think (WITH patch comes from the prior release cycle and was committed in this release), not to think about one scenario but about all possible scenarios in a more wide audience -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
> I think the best thing we could do overall is to set release dates and > stick to them. If your patch is not ready, well, at least it will get > out in a defined amount of time. Right now, the *real* problem with it > being pushed to the next release is you don't know how successful some > other guy will be at persuading us to delay the next release. +1, LOL. Let's not forget that we've already got CTE, window functions, partial vacuums, and column-level permissions, all of which are major features that should benefit a lot of people. I hope Hot Standby gets committed but even if it doesn't, I'm still going to get a lot of benefit out of this release, so I'd like it to happen on some sort of reasonable time scale. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Joshua Brindle wrote:
Stephen Frost wrote:
* Joshua Brindle (met...@manicmethod.com) wrote:
They are separate. If you look at the patches you'll see a pgace
part, this is where the core interfaces to the security backends, and
you'll see a rowacl backend and an sepgsql backend.
Right, guess it wasn't clear to me that the PGACE bits for row-level
access control could be used independently of SELinux (and maybe even on
systems that don't have SELinux..?).
Sure, if you look at pgaceHooks.c you'll see:
It is basically possible to implement something like "PostgreSQL
Label Security" on PGACE framework.
But I don't want to discuss it now, because it surely burst
SE-PostgreSQL until v8.4 beta.
If desired, I'll queue it my todo list next to SE-PostgreSQL...
bool
pgaceExecScan(Scan *scan, Relation rel, TupleTableSlot *slot)
{
/* Hardwired DAC checks */
if (!rowaclExecScan(scan, rel, slot))
return false;
switch (pgace_feature)
{
#ifdef HAVE_SELINUX
case PGACE_FEATURE_SELINUX:
if (sepgsqlIsEnabled())
return sepgsqlExecScan(scan, rel, slot);
break;
#endif
default:
break;
}
return true;
}
Notice the rowacl call outside of the HAVE_SELINUX ifdefs
FYI:
In the earlier version, these are mutually exclusive, so we could
not apply SE-PostgreSQL, when a binary is built with RowAcl feature.
However, Bruce Momjian suggested it is not proper manner in
PostgreSQL, because it intend to wrap all available features
into a single binary due to packaging benefit, and all the
available options should be configured by runtime.
In addition, IIRC, Peter E suggested it is not symmetrical
that we cannot apply both of DAC and MAC on tuples simultaneously,
although SE-PostgreSQL applies MAC on tables/columns which
PostgreSQL has DAC features on.
So, I add a support simultaneous DAC&MAC.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Ron Mayer writes: > Tom Lane wrote: >> I think the best thing we could do overall is to set release dates and >> stick to them. > On the other hand, we might be better throwing out release dates > and releasing at the end of any Commit Fest where there is enough > demand/interest. > Then we could release 8.4 now, with few objections since people would > know that if Hot Standby has enough demand it could be released within one > commitfest of it being in good shape. Huh? The people who'd been working with the expectation of completing their patch in the *next* fest would scream loud and long at having the release schedule pulled out from under them. Any development plan with more than a two-month time horizon would turn into a game of schedule russian roulette. The only way this works without having a lot of pissed-off developers is if we actually release a lot more often, which is not going to fly. We don't have the manpower to manage that, and we don't have users that want it, either. (They might like it better if we had a better upgrade-in-place story, but ...) regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Tom Lane wrote: > Joshua Brindle writes: >> Tom Lane wrote: >>> Right, which is why it's bad for something like a foreign key constraint >>> to expose the fact that the row does exist after all. > >> Once again, this is not an issue for us. > > Yes it is an issue; claiming it isn't doesn't make it so. You just > stated, in effect, that you don't implement data hiding in the > filesystem because it would break standard Unix filesystem semantics. > How is that consistent with your opinion that it's okay to break > standard SQL semantics in order to implement data hiding in a database? > > The question of whether there is a covert channel is only a small part > of my complaint here. If it's the judgement of security experts that > that's an acceptable thing, that's fine, it's their turf. But SQL > behavior is my turf, and I'm not happy with discarding fundamental > semantic properties. Do you forget a GUC option: sepostgresql_row_leve = on/off ? It was a requirement from Simon Riggs at Oct 2008, IIRC. Its original purpose is to reduce storage consumption due to the security label of each tuples, however, it can allow users to choose the granularity of access controls in finally. I can understand you have a complaint about covert channels via PK/FK due to the row-level granularity. However, in other hand, we can already see a commercial producet which provides row-level access controls without any cares about covert channels. It shows a fact that not negligible number of users accept row-level granularity, even if it has covert channels. What is needed is an explicit documentation about covert channels and providing a few options to users. It is not a reasonable stance to deny anything due to a single item which is acceptable some of people, at least. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Tom Lane wrote: > Heh. The reason we wanted a short 8.3 cycle was so we could push out > patches that had been held over from 8.2. We are going to have exactly > no credibility if we tell Simon et al "we're pushing these patches to > 8.5, but don't worry, it'll be a short release cycle". > > I think the best thing we could do overall is to set release dates and > stick to them. On the other hand, we might be better throwing out release dates and releasing at the end of any Commit Fest where there is enough demand/interest. Then we could release 8.4 now, with few objections since people would know that if Hot Standby has enough demand it could be released within one commitfest of it being in good shape. Likewise the SE* guys would be aware that if they want that patch to drive a release, they'd need to round up more visible demand. Heck, 8.4 could have been released a whole commitfest ago if enough people think FSM is the killer feature in that one. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Andrew Sullivan wrote: On Tue, Jan 27, 2009 at 12:41:36PM -0500, Stephen Frost wrote: * Gregory Stark (st...@enterprisedb.com) wrote: It does seem weird to simply omit records rather than throw an error and require the user to use a where clause, even if it's something like WHERE pg_accessible(tab). […] do row-level security and security labels. Requiring a where clause or you throw an error would certainly make porting applications that depend on that mechanism somewhat difficult, and doesn't really seem like it'd gain you all that much... Throwing an error would entail a side-channel leak that would not be acceptable to the security community, I bet. That said, I have reservations, along the lines of Peter E's, that the early design-level objections to the approach were never answered. I certainly never got any real answer to questions I asked, for what it's worth. I will note that I tried to have a look at the literature on this topic. As I started to read, it became obvious that it was copious, but pretty well-determined. What bothered me most about the answers I got was that there never seemed to be an answer to "please outline the design principles" except for "it's what SE-Linux does". The OS-level control rules seemed to me to be totally foreign to the database world, precisely because ACID is a problem in databases in a way it isn't for filesystems under the traditional UNIX model. I formed the impression -- only an impression, mind, that there was a poor fit between SE-Linux and database systems, and that the proponents had decided that enough caulk (in the form of "don't do that") would seal the gap. As I noted before, there is a symmetrical structure between OS and DBMS. In operating system, a process accesses objects (like file, socket, ...) managed by operating system via system calls. Its security system (filesystem permission, SELinux, ...) acquires the request and applies its access control rules. In DBMS, a client accesses database objects managed by DBMS via SQL queries. Its security system (Database ACL, SE-PostgreSQL, ...) aquires the request and applies its access control rules. We have similar structures everywhere, not only DBMS and OS. What we should pay attention is a subject entity accesses via a method provided by object managers (DBMS, OS, ...), and object managers apply its rules to decide either "allowed" or "denied" on acquired request. I haven't (obviously) been paying much attention to this topic since, but I detect something of the same sort of response in the recent discussion. Maybe the goal isn't explicit enough. If the goal is compliance with some set of well-defined tests, what are they? If the goal is buzzword compliance, what are the tests of that (to the extent there ever are some)? If the goal is just "security enhancement", I confess that I am still unable to understand the definitions of "security" and "enhancement" such that I think we have some operationalization of what the patch is supposed to provide. The most significant feature is centralized access control policy between OS and DBMS. Did you attend PGcon2008? I talked here we should consider the value of information asset is independent from the way to store them. Needless to say, the value of information asset is decided by its contents. If your credit card number is recorded on a paper, do you think it has lesser value than recorded on database? Thus, from the viewpoint of security, we need to consider the way to apply unified centralized access controls. SELinux works as "security server". It enables to provide a centralized access control decision any other object managers (like, Linux kernel, X-window, PostgreSQL, ...). It is quite consistent because of common security policy and common clearance of entities. It finally enables to apply centralized access control policy on whole of application stack. Please note that 95% of attacks in 2008 targeted to web system, so it gives a nightmare for security folks. Thanks, I know there are people who think this is cool. I guess, if I were running the circus, I'd want to know what's cool about it, and why. Then maybe the project would be in a position to understand whether that kind of cool is the way it wants to be. But without a clear problem statement, and a roadmap of how the patches solve the problem, I'm at a loss. And last I checked (which was, admittedly, not today), the project pages didn't have that information. A -- OSS Platform Development Division, NEC KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Tue, 2009-01-27 at 21:07 -0500, Tom Lane wrote: > Robert Treat writes: > > The more I think about it, the more I feel that where we failed for 8.3 was > > not having a short 8.4 cycle lined up, which would give more freedom to > > bump > > patches to the next release. > > Heh. The reason we wanted a short 8.3 cycle was so we could push out > patches that had been held over from 8.2. We are going to have exactly > no credibility if we tell Simon et al "we're pushing these patches to > 8.5, but don't worry, it'll be a short release cycle". > > I think the best thing we could do overall is to set release dates and > stick to them. If your patch is not ready, well, at least it will get > out in a defined amount of time. Right now, the *real* problem with it > being pushed to the next release is you don't know how successful some > other guy will be at persuading us to delay the next release. +1 Joshua D. Drake > > regards, tom lane > -- PostgreSQL - XMPP: jdr...@jabber.postgresql.org Consulting, Development, Support, Training 503-667-4564 - http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Robert Treat writes: > The more I think about it, the more I feel that where we failed for 8.3 was > not having a short 8.4 cycle lined up, which would give more freedom to bump > patches to the next release. Heh. The reason we wanted a short 8.3 cycle was so we could push out patches that had been held over from 8.2. We are going to have exactly no credibility if we tell Simon et al "we're pushing these patches to 8.5, but don't worry, it'll be a short release cycle". I think the best thing we could do overall is to set release dates and stick to them. If your patch is not ready, well, at least it will get out in a defined amount of time. Right now, the *real* problem with it being pushed to the next release is you don't know how successful some other guy will be at persuading us to delay the next release. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On 1/27/09 6:57 PM, "Greg Smith" wrote: > On Tue, 27 Jan 2009, Chad Sellers wrote: > >> I'll speak to this a bit (Josh is also a Tresys employee). I can't say who >> my customers are, but I can speak to their needs. They really need row-level >> mandatory access controls (so both). > > From the perspective of what this would buy as far as this feature being a > PostgreSQL advocacy point, one of the questions Tom asked about a bit > upthread is still a bit hazy here. There are commercial database > offerings selling into the "trusted" space already. While the use-cases > you describe make perfect sense, I don't think it's clear to everyone yet > if there's a unique draw to a PostgreSQL + selinux solution that the class > of customers you're talking about would prefer it to purchasing one of > those products. Is the cost savings the main driver here, or is there > something else about a secure LAPP stack that makes it particularly > compelling? > Cost savings may be a driver, but it's certainly not the main driver. A problem with the current systems (e.g. Oracle) is that they largely operate in their own world. Oracle Label Security labels do not extend outside the database to the rest of the system, which makes it impossible to build certain things. For instance, you can't really build a trusted LAPP stack. With SE-PostgreSQL, the label used for access control is bound by the kernel and used by it and the other components of the stack (apache, PostgreSQL). We can even extend all the way to the end system using labeled IPSec. Another major drawback to the currently available trusted databases is that they have hard-coded policy rules rather than flexible ones. While these hard-coded rules may be appropriate in some scenarios, they often end up being impractical. For instance, any sort of pipeline (like that of my example 3) is difficult if not impossible to implement on most of these hard-coded systems. Additionally, changing the label in most of these systems requires a privilege that lets you bypass the policy rules, while a flexible Type Enforcement system (like SE-PostgreSQL) allows you to specify exactly how relabels should be allowed within the policy. I'll be happy to provide more details where required. Hopefully that provided a little light. Thanks, Chad Sellers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Joshua Brindle wrote:
Tom Lane wrote:
Ron Mayer writes:
It seems to me that there are two different standards to which this
feature
might be held.
Is the goal
a) SEPostgres can provide useful rules to add security to some
specific applications so long as you're careful to avoid crafting
policies that produce bizarre behaviors (like avoiding restricing
access to foreign key data you might need). On the other hand it
gives you enough rope to hang yourself and produce weird results
that don't make sense from a SQL standard point of view if you
aren't careful matching the SEPostgres rules with your apps.
or
b) SEPostgreSQL should only give enough rope that you can not
craft rules that produce unexpected behavior from a SQL point
of view; and that it would be bad if one can produce SEPostgres
policies that produce unexpected SQL behavior.
With my other hat on (the red one) what I'm concerned about is whether
this patch will ever produce a feature that I could turn on in the
standard Red Hat/Fedora build of Postgres. Right at the moment it seems
that the potential performance hit, for users who are *not using*
SEPostgres but merely have to use a build in which it is present,
might be bad enough to guarantee that that will never happen.
According to the comments in security/sepgsql/core.c:
/*
* sepgsqlIsEnabled
*
* This function returns the state of SE-PostgreSQL when PGACE hooks
* are invoked, to prevent to call sepgsql() functions when
* SE-PostgreSQL is disabled.
*
* We can config the state of SE-PostgreSQL in $PGDATA/postgresql.conf.
* The GUC option "sepostgresql" can have the following four parameter.
*
* - default: It always follows the in-kernel SELinux state. When it
*works in Enforcing mode, SE-PostgreSQL also works in
*Enforcing mode. Changes of in-kernel state are delivered
*to userspace SE-PostgreSQL soon, and SELinux state
*monitoring process updates it rapidly.
* - enforcing : It always works in Enforcing mode. In-kernel SELinux
*has to be enabled.
* - permissive : It always works in Permissive mode. In-kernel SELinux
*has to be enabled.
* - disabled : It disables SE-PostgreSQL feature. It works as if
*original PostgreSQL
*/
and in the hooks there is a pgace_feature that turns off the checks:
void
pgaceGramAlterRelation(Relation rel, HeapTuple tuple, DefElem *defel)
{
switch (pgace_feature)
{
#ifdef HAVE_SELINUX
case PGACE_FEATURE_SELINUX:
if (sepgsqlIsEnabled())
{
sepgsqlGramAlterRelation(rel, tuple, defel);
return;
}
break;
#endif
default:
break;
}
if (defel)
ereport(ERROR,
(errcode(ERRCODE_PGACE_ERROR),
errmsg("unable to set security
attribute of table "
"via ALTER TABLE")));
}
So the pgace_feature turns off the backend call, there is an extra
function call, and a branch but that shouldn't cause the kind of
performance degradation you are talking about.
This hook is only available when an enhanced security feature is
enabled, so I injected ereport() at the tail.
(It is invoked on ALTER TABLE ... SECURITY_LABEL = '...';)
However, most of hooks do nothing or don't change existing behavior
when enhanced security is disabled.
So, I can't understand why it gives adverse affects in performances.
I can admit it needs additional steps to invoke empty functions at least.
However, using "static inline" was arguable in the previous discussion
due to the GCC dependency.
Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Tuesday 27 January 2009 19:04:49 Tom Lane wrote: > Robert Treat writes: > > On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote: > >> We have tried the short release cycle before, it was called 8.2. It > >> fails, remarkably. > > > > I think this is a bit of revisionsit history. > > JD got the release number wrong, it was 8.3, but otherwise there's no > revisionism involved: > http://archives.postgresql.org/pgsql-hackers/2006-12/msg00786.php > The revisionism was that of "remarkable failure". That was our shortest release cycle in the modern era. And it didn't have the advantage of the commitfest process. But I think what is important here is to recognize why it didn't work. Once again we ended up with large, complex features (HOT, tsearch) that people didn't want to wait 14 months to see if they missed the 8.3 release. And yes, most of these same arguements were raised then... "full text search is killer feature", "whole applications are waiting for in-core full text search", "hot will give allow existing customers to use postgres on a whole new level", "not fair to push back patches so long when developers followed the rules", "sponsors wont want to pay for features they wont see for years", "developers dont want to wait so long to see features committed", and on and on... The more I think about it, the more I feel that where we failed for 8.3 was not having a short 8.4 cycle lined up, which would give more freedom to bump patches to the next release. > The theme that our release cycles are too long is not exactly new, > of course, eg > http://archives.postgresql.org/pgsql-hackers/2000-05/msg00574.php > http://archives.postgresql.org/pgsql-hackers/2001-06/msg00766.php > http://archives.postgresql.org/pgsql-hackers/2003-11/msg00889.php Yeah, I remember all that, and I think you'll find that I mostly was on the other side of this issue :-) But many of the arguments from back then don't apply any more. Remember when you couldn't depend on pg_dump giving you dumps in the right order? Now that was a recipe for painful upgrades. With things like Slony, it's now possible to upgrade a majority of the Postgres installations with extremely minimal downtime. (And yes, I happen to have one that wont work with slony, but hey...) > but by now I think we've learned to stop banging our heads against > that particular rock. One-year major cycles work for this project, > shorter ones are wishful thinking. > Do they? 1 year cycles certainly don't solve the problem of being left with big/complex left over patches. They don't decrease the amount of time (as a percentage) we spend in freeze/beta/release mode. And we don't even get them out in 1 year; this 1 year cycle looks like at least 15 months. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Here is morning now, so I started to follow the discussion now... Stephen Frost wrote: > * Gregory Stark (st...@enterprisedb.com) wrote: >> It does seem weird to simply omit records rather than throw an error and >> require the user to use a where clause, even if it's something like WHERE >> pg_accessible(tab). It was an implementation of very earlier version of SE-PostgreSQL. (Maybe, its revision number was still less than 500.) It rewrites WHERE clause of given queries, but Tom suggested such a query rewrite easily makes a bug and hard to maintain in the future, so I removed the code and put a hook in ExecScan(), which featch a tuple from relation and checks condition. (I think it was a good suggestion. It also enables to reduce the scale of SE-PostgreSQL patches.) Indeed, it requires additional checks and disables a few kind of optimization, when these enhanced-security features are activated. However, I made clear some times that we assume security focused users don't give their first priority on performance. I can understand performance is a significant factor for database management system, so the default of these features are *disabled* unless user explicitly activate them. > It is weird from an SQL perspective, I agree with you there. On the > other hand, it's what the security community is looking for, and is > what's implemented by other databases (Oracle, SQL Server...) that > do row-level security and security labels. Requiring a where clause > or you throw an error would certainly make porting applications that > depend on that mechanism somewhat difficult, and doesn't really seem > like it'd gain you all that much... -- OSS Platform Development Division, NEC KaiGai Kohei -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Tuesday 27 January 2009 18:51:01 Tom Lane wrote: > Robert Treat writes: > > Now I am starting to think that we cannot prevent large patches from > > showing up at the end of a cycle no matter what, and the only way to > > really "solve" that problem is to lesson the pain of getting bumped from > > a release. Ie. instead of being bump meaning you must wait 12-14 months > > till next release, we move toward more of a 6 month cycle of development. > > I really can't see going in that direction. In the first place, no one > wants to spend a third or more of the time in beta mode. Yeah, I was thinking that, but the truth is we do that now. We released last Febuary right? and we're looking at releasing (optimisttically) May 1st, right? So thats 15months, of which November - May (6 months) will have been feature freeze / beta / rc phase of development. > In the > second place, if the problem is big patches that take a long time to > develop, halving the length of the development cycle is no solution. > (If it did work, our plea to break large patches into segments landing > in different commitfests would have had more results.) I think this is a mis-assesment of our problem. The problem is not that big patches take a long time; not so much that they don't, just that is not a problem we can solve... "Hey Simon, code faster!" is not going to work ;-) The problem is that the pain point is extremely high for missing a given release cycle. If you don't make a specific release, you have a 12-14 month wait for feature arrival. Given that choice, someone who deperately need (aka wants) HS/SEPostgres/Win32/HOT/IPU/etc... will likely be willing to push a release 3-6 months for that one feature. Incidentally, this is probably why people didnt worry about making a given commitfest. The pain point was low, so there was no percieved need to rework a patch for a specific commit, since there was another one just a couple months away. However, we still see a rush of patches at the final freeze because people know that "there is no tommorrow" at that point. > In the third > place, unless we get an upgrade-in-place process that works all the > time, we would be looking at maintaining twice as many back branches > in order to provide the same kind of release lifespan we have today. > We are at the limit of what we can realistically do in back-branch > maintenance already :-( > Yeah, I can't argue with that. I'm not sure it's an unsolvable problem though; if odd/even release maintenance doesn't sound good, we could do something like ubuntus LTS, where we pick 1 release every 3 years to make a long-term support commitment (I think 5 years is our current max), and keep other releases on a shorter lifespan (1 or 2 years). Certainly having IPU (or is that UIP?) would make that an easier decision. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Robert Treat writes: > On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote: >> We have tried the short release cycle before, it was called 8.2. It >> fails, remarkably. > I think this is a bit of revisionsit history. JD got the release number wrong, it was 8.3, but otherwise there's no revisionism involved: http://archives.postgresql.org/pgsql-hackers/2006-12/msg00786.php The theme that our release cycles are too long is not exactly new, of course, eg http://archives.postgresql.org/pgsql-hackers/2000-05/msg00574.php http://archives.postgresql.org/pgsql-hackers/2001-06/msg00766.php http://archives.postgresql.org/pgsql-hackers/2003-11/msg00889.php but by now I think we've learned to stop banging our heads against that particular rock. One-year major cycles work for this project, shorter ones are wishful thinking. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Tue, 27 Jan 2009, Chad Sellers wrote: I'll speak to this a bit (Josh is also a Tresys employee). I can't say who my customers are, but I can speak to their needs. They really need row-level mandatory access controls (so both). From the perspective of what this would buy as far as this feature being a PostgreSQL advocacy point, one of the questions Tom asked about a bit upthread is still a bit hazy here. There are commercial database offerings selling into the "trusted" space already. While the use-cases you describe make perfect sense, I don't think it's clear to everyone yet if there's a unique draw to a PostgreSQL + selinux solution that the class of customers you're talking about would prefer it to purchasing one of those products. Is the cost savings the main driver here, or is there something else about a secure LAPP stack that makes it particularly compelling? -- * Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Robert Treat writes: > Now I am starting to think that we cannot prevent large patches from showing > up at the end of a cycle no matter what, and the only way to really "solve" > that problem is to lesson the pain of getting bumped from a release. Ie. > instead of being bump meaning you must wait 12-14 months till next release, > we move toward more of a 6 month cycle of development. I really can't see going in that direction. In the first place, no one wants to spend a third or more of the time in beta mode. In the second place, if the problem is big patches that take a long time to develop, halving the length of the development cycle is no solution. (If it did work, our plea to break large patches into segments landing in different commitfests would have had more results.) In the third place, unless we get an upgrade-in-place process that works all the time, we would be looking at maintaining twice as many back branches in order to provide the same kind of release lifespan we have today. We are at the limit of what we can realistically do in back-branch maintenance already :-( regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Tuesday 27 January 2009 10:34:59 Joshua D. Drake wrote: > On Tue, 2009-01-27 at 06:40 +0100, Pavel Stehule wrote: > > > 8.4-stable > > > 8.4-experimental > > > > > > stable is everything that stable is. PostgreSQL at its best. > > > > I dislike this idea - it's same like short processed 8.5 - > > Actually it isn't because we wouldn't accept features into > 8.4-experimental. The only thing we would accept into 8.4-experimental > would be bug fixes that would automatically be ported up to 8.5 (or > perhaps the other way around). We would still continue to build 8.5 as > normal. > > > that is > > more simple. > > We have tried the short release cycle before, it was called 8.2. It > fails, remarkably. > I think this is a bit of revisionsit history. While I'd agree it didn't work, the cycle was shorter... or to put it another way, would you say that the commitfest model failed miserably? should we scrap that for next cycle? I wonder... Feb 1 - all remaining patches bump / beta starts March 15th - beta ends / rc starts (note, giving 3 months for beta/rc, since we had a longer dev round) May 1st - release 8.4, open 8.5 dev June 1st - first 8.5 commitfest (we don't worry about short May because we have built up patche queue) July - second round of dev August - second/final commitfest Sept - beta opens October - rc opens November - release 8.5, open 8.6 December - first commitfest for 8.6 Jan 2010 - second dev cycle Feb - final commitfest March - 8.6 beta April - 8.6 rc May 2010 - release 8.6 -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On 1/27/09 4:40 PM, "Ron Mayer" wrote: > Joshua Brindle wrote: >>> FWIW, as you know, sepostgresql is already included in Fedora. You can >>> continue shipping it as a seperate RPM set. >> >> That is non-ideal. Getting the capability in to the standard database >> shipped with RHEL is very important to me and my customers. > > Could you speak - even in general terms - about who your customers are > and what kinds of needs (is row-level acls the most important to them? > mandantory access control at the table level? both?) they have? > I'll speak to this a bit (Josh is also a Tresys employee). I can't say who my customers are, but I can speak to their needs. They really need row-level mandatory access controls (so both). I'll give a few examples that will hopefully help here. 1) One customer had several networks, each with a different classification. When a user needed to find anything, it was very painful as they would have to log into each network one at a time to search for anything. What they wanted to do was have a trusted database with a combined index of all the networks. They wanted to be able to write a flexible policy that could grant access to individual entries in the database based on what network the request came from in addition to the security clearance of the user requesting data. 2) Another example that we've been asked for repeatedly but had to turn away as the capability did not yet exist is a trusted LAMP/LAPP stack (Note that KaiGai is also working on the apache portion of this to provide a complete trusted LAPP stack). Under this model, individual web scripts can be run with a specific type. Combined with an SE-PostgreSQL policy, this gives the ability to restrict what a specific script can access. Additionally, as SE-PostgreSQL ties back in to the operating system mandatory access control mechanism, we can tie the type of the script back to the type of the actual user making the request. Coupled with labeled IPSec, this means we can control access to data in the database based on the clearance or role (or anything else you want to represent in their type) of the user on their end system. 3) A customer wanted to implement an approval process that required several steps. Without SE-PostgreSQL, we were forced to implement this by making lots of copies. Stage 1 would approve the package and copy it into Stage 2's inbox. We would grant each stage write access to the next stage's inbox in order to enforce information flow. This was very expensive, and didn't scale well. With SE-PostgreSQL, we could leave the data where it was and simply relabel the row(s). Each stage would be granted the ability to relabel from its type to the type of the next stage. No copies are necessary. I hope those help. I realize that many of you may not be used to dealing with customers who have such stringent security requirements, but if SE-PostgreSQL gets merged, that could change. Thanks, Chad Sellers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
That's modest. I've talked to several oracle and db2 shops that want a standby for reporting that has relatively easy setup/maintenance (handling ddl is a big part of this) and the HS feature your working on will give them something as good as what they are getting now. So yeah, HS appeals to future users as well. I've talked to some of my clients, and while they *want* synch or near-synch HS, even slow HS is useful to them *now*. One client is planning on deploying a rather complex FS cloning infrastructure just to have a bunch of reporting, testing and read-only search databases they need. They'd be thrilled with an HS feature which produced DBs which were an hour out of date (or even 6 hours out of date), but ran read-only queries. --Josh. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Tuesday 27 January 2009 11:56:51 Simon Riggs wrote: > On Tue, 2009-01-27 at 11:36 -0500, Tom Lane wrote: > > David Fetter writes: > > > On Mon, Jan 26, 2009 at 03:12:02PM -0500, Tom Lane wrote: > > >> I don't think this is correct. > > > > > > I do. > > > > > > People literally grab my shoulder and ask when we'll have it. > > > > Do these people understand the difference between HS and a complete > > replication solution? Are they still as excited after you explain > > the difference? > > Yes, I think they do. > > http://www.postgresql.org/community/survey.55 > These people seem to understand also. > > Sync rep *is* important, but it opens up new classes of applications for > us. As does SEP. Both of those are more speculative and harder to > measure, but we've seen big impact before from this type of new feature. > > HS appeals to current users. Current users aren't so worried about new > applications, they look forward to being able to run queries on their > currently idle standby servers. > That's modest. I've talked to several oracle and db2 shops that want a standby for reporting that has relatively easy setup/maintenance (handling ddl is a big part of this) and the HS feature your working on will give them something as good as what they are getting now. So yeah, HS appeals to future users as well. -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
Marko Kreen wrote: > On 1/27/09, Peter Eisentraut wrote: >> On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote: >> > Such app already exists: >> > >> > http://ozlabs.org/~jk/projects/patchwork/ >> > >> > So it's a matter of just setting it up. >> >> >> I was in fact in the process of setting that up just now. :-) > > Nice to know. :) I feel that even if we decide to do our own > solution it would be good to try existing solution first. IIRC, we already installed and tried this a while ago. I don't remember exactly what it failed on, but there was something pretty clear. But maybe it's been fixed by now. //Magnus -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Monday 26 January 2009 15:13:56 dp...@pgadmin.org wrote: > On 1/26/09, Josh Berkus wrote: > > All, > > > >>> 1) having the last CF on Nov. 1 was a mistake. That put us square in > >>> the path of the US & Christian holidays during the critical integration > >>> phase .. > >>> which means we haven't really had 3 months of integration, we've had > >>> *two*. > > > > Actually, I'm thinking about this again, and made a mistake about the > > mistake. The *original plan* was that we were not going to accept any > > new patches for Nov-CF. Just revised patches from eariler Fests. We > > didn't stick to that, which is mostly why we are still reviewing now. > > I don't recall us discussing that, but it sounds like it might help next > cycle. > What would be the significance of opening up the tree to future development between the last commitfest and last commitfest -1, if no new patches could be introduced? Essentially this is where we are at now... November commit fest finished, December we "re-opened" for development, and we're in the January commitfest where no new features have been accepted. The problem is what to do when we get to the end of the commit fests, and we have a few reamining (invariably large/complex) patches that people don't want to push. I had been leaning toward the idea of pushing the 8.4 release back six months, but reopening development for 2-3 more development/commitfest cycles, but I am starting to think this is moving things in the wrong direction. Now I am starting to think that we cannot prevent large patches from showing up at the end of a cycle no matter what, and the only way to really "solve" that problem is to lesson the pain of getting bumped from a release. Ie. instead of being bump meaning you must wait 12-14 months till next release, we move toward more of a 6 month cycle of development. I'm not sure it's feasible to boil down beta/rc phase to two months, tough it seems possible if we were strict about bumping features that aren't ready, and if our development cycles only went 4 months. For end users who are concerned about continuous upgrading, we might think about putting restrictions on every other release (ie. require binary or data file level compatability with 8.4 for the 8.5 release, and remove that restriction for 8.6) to lesson the upgrade path. (alternativly, a working IPU plan could make that less of an issue) -- Robert Treat Conjecture: http://www.xzilla.net Consulting: http://www.omniti.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Joshua Brindle wrote: >> FWIW, as you know, sepostgresql is already included in Fedora. You can >> continue shipping it as a seperate RPM set. > > That is non-ideal. Getting the capability in to the standard database > shipped with RHEL is very important to me and my customers. Could you speak - even in general terms - about who your customers are and what kinds of needs (is row-level acls the most important to them? mandantory access control at the table level? both?) they have? I'm guessing a better understanding of how real-world users would use this feature would be enlightening. > Since you can turn this off with GUC I don't see why it makes sense to > ship 2 databases (nevermind the maintenance issues) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Mon, Jan 26, 2009 at 08:28:32PM -0500, Tom Lane wrote: > Hmm, you think selinux people read pgsql-announce? Maybe not, but it got it onto LWN, which is a lot more people. Have a nice day, -- Martijn van Oosterhout http://svana.org/kleptog/ > Please line up in a tree and maintain the heap invariant while > boarding. Thank you for flying nlogn airlines. signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
On Tue, 2009-01-27 at 15:46 -0500, Tom Lane wrote: > Peter Eisentraut writes: > > Not to pick on you personally, but this is the kind of review that should > > have > > happened six months ago, not during a "why is our development process > > inadequate" discussion on the eve of beta. > > Right now, today, in this thread, is the first time that we've had any > opportunity to debate the design of SEPostgres with knowledgeable people > other than KaiGai-san. It would likely be better if we started a new > thread with a more appropriate title, but I see nothing wrong with > asking pretty fundamental questions. Except that Bruce and I already checked detailed documentation references on this very topic months ago. Check with Bruce; he was careful to point those things out to me, so I'm sure he'll do the same for you. I'm satisfied, on this point. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
* Devrim GÜNDÜZ (dev...@gunduz.org) wrote: > On Tue, 2009-01-27 at 15:03 -0500, Tom Lane wrote: > > With my other hat on (the red one) what I'm concerned about is whether > > this patch will ever produce a feature that I could turn on in the > > standard Red Hat/Fedora build of Postgres. > > FWIW, as you know, sepostgresql is already included in Fedora. You can > continue shipping it as a seperate RPM set. hrmpf, I wonder if that's why RH hasn't been as interested in pushing for inclusion upstream... Maybe the feel that's a workable solution? I wouldn't agree... but I don't run RH. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
Devrim GÜNDÜZ wrote: On Tue, 2009-01-27 at 15:03 -0500, Tom Lane wrote: With my other hat on (the red one) what I'm concerned about is whether this patch will ever produce a feature that I could turn on in the standard Red Hat/Fedora build of Postgres. FWIW, as you know, sepostgresql is already included in Fedora. You can continue shipping it as a seperate RPM set. That is non-ideal. Getting the capability in to the standard database shipped with RHEL is very important to me and my customers. Since you can turn this off with GUC I don't see why it makes sense to ship 2 databases (nevermind the maintenance issues) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Tue, 2009-01-27 at 15:03 -0500, Tom Lane wrote: > > With my other hat on (the red one) what I'm concerned about is whether > this patch will ever produce a feature that I could turn on in the > standard Red Hat/Fedora build of Postgres. FWIW, as you know, sepostgresql is already included in Fedora. You can continue shipping it as a seperate RPM set. -- Devrim GÜNDÜZ, RHCE devrim~gunduz.org, devrim~PostgreSQL.org, devrim.gunduz~linux.org.tr http://www.gunduz.org signature.asc Description: This is a digitally signed message part
Re: [HACKERS] 8.4 release planning
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Stephen Frost writes: > > Personally, I think it'd be terrible to implement the suggestion that > > started this sub-thread since it breaks with what is currently done > > elsewhere and what the users of this feature would expect. > > Upthread we were being told that this patch breaks new ground and will > offer capability available nowhere else. Now I'm hearing that it's just > a "me too" patch to catch up with capability already available from N > commercial vendors. Which is it? argh, it's a combination, in the end. Oracle and SQL Server offer row level security, that's something we don't have today and is provided through PGACE and is a big piece of the security labels/context part of the high security RDBMS world. Neither of them (far as I know..) interoperate with a OS-level policy system to provide that additional integration with the rest of the system as a whole (the SE-Linux bits). I wasn't sure how easy they were to seperate and to use seperately. It looks like they can be used independently, which is great, and means you could implement row level security on a BSD platform, but you wouldn't get the integration with the OS policy unless you hooked in with the Trusted BSD system (which I think actually can be done through an SE-Linux userland port.. but I've never played with it). Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
Tom Lane wrote: Stephen Frost writes: Personally, I think it'd be terrible to implement the suggestion that started this sub-thread since it breaks with what is currently done elsewhere and what the users of this feature would expect. Upthread we were being told that this patch breaks new ground and will offer capability available nowhere else. Now I'm hearing that it's just a "me too" patch to catch up with capability already available from N commercial vendors. Which is it? It is like the difference between Trusted Solaris (really all the old trusted OS's) and SELinux. They both implement mandatory access control and both implement Bell and LaPadula as needed by the government/military but SELinux, via type enforcement, goes further to provide a completely flexible mandatory access control system. SELinux is useful to meet all sorts of security goals, from system and application integrity to data pipelining and confidentiality. The SELinux community believes this sort of access control is important to not only the military but commercial and even small scale systems. Further, because sepostgresql integrates well with SELinux the same system wide access controls flow seamlessly into the database. Are you able to access secret data on the filesystem? If so you'll be able to access secret data in the database. Are you able to update accounting information in the filesystem? Then you'll be able to update accounting information in the database. This also integrates with KaiGai's other work to SELinux-ize apache so that an apache server can run a user script from a users home directory and a type transition occurs to run the script in the appropriate domain for that user, then when that script accesses the database they'll have only the access that users script should have. This kind of end-to-end integration with mandatory access control is certainly ground breaking and isn't just the same ol' same ol' that other database vendors are doing (and have been doing for quite some time). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
* Tom Lane (t...@sss.pgh.pa.us) wrote: > BTW, whilst we are being beat about the head and shoulders with how > Oracle et al already have features like this, it is entirely appropriate > to wonder how come it's not in the standard. Those companies surely > pretty much control the standards committee, and they have managed to > push a ton of rather dubious things into the last couple of SQL updates. > If row-level security is such a mess that they couldn't standardize it, > that tells me something. For my 2c, for whatever it's worth, it's a combination of a specialized user base and the fact that this kind of security used to only be in a seperate product (eg: Trusted Oracle). Perhaps it will be in the standard some day, I don't think it's unreasonable to think that. Certainly it'd be nice if it was already there. Thanks, Stephen signature.asc Description: Digital signature
Re: Commitfest infrastructure (was Re: [HACKERS] 8.4 release planning)
On 1/27/09, Peter Eisentraut wrote: > On Tuesday 27 January 2009 15:51:02 Marko Kreen wrote: > > Such app already exists: > > > > http://ozlabs.org/~jk/projects/patchwork/ > > > > So it's a matter of just setting it up. > > > I was in fact in the process of setting that up just now. :-) Nice to know. :) I feel that even if we decide to do our own solution it would be good to try existing solution first. -- marko -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Stephen Frost writes: > Personally, I think it'd be terrible to implement the suggestion that > started this sub-thread since it breaks with what is currently done > elsewhere and what the users of this feature would expect. Upthread we were being told that this patch breaks new ground and will offer capability available nowhere else. Now I'm hearing that it's just a "me too" patch to catch up with capability already available from N commercial vendors. Which is it? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Peter Eisentraut writes: > On Tuesday 27 January 2009 16:36:50 Stephen Frost wrote: >> The SQL spec doesn't define row-level security, and coming >> up with something willy-nilly on our own doesn't really strike me as the >> best approach. > Exactly. But there is plenty of discussion on that elsewhere. BTW, whilst we are being beat about the head and shoulders with how Oracle et al already have features like this, it is entirely appropriate to wonder how come it's not in the standard. Those companies surely pretty much control the standards committee, and they have managed to push a ton of rather dubious things into the last couple of SQL updates. If row-level security is such a mess that they couldn't standardize it, that tells me something. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
* Tom Lane (t...@sss.pgh.pa.us) wrote: > Peter Eisentraut writes: > > Not to pick on you personally, but this is the kind of review that should > > have > > happened six months ago, not during a "why is our development process > > inadequate" discussion on the eve of beta. > > Right now, today, in this thread, is the first time that we've had any > opportunity to debate the design of SEPostgres with knowledgeable people > other than KaiGai-san. It would likely be better if we started a new > thread with a more appropriate title, but I see nothing wrong with > asking pretty fundamental questions. I agree with asking the questions, but I don't like the immediate assumption that we're going to have to kick the patch because someone asked a question or suggested an alternative design unless we actively decide that's the approach we want to go and it requires a serious rework of the patch. Personally, I think it'd be terrible to implement the suggestion that started this sub-thread since it breaks with what is currently done elsewhere and what the users of this feature would expect. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
* Peter Eisentraut (pete...@gmx.net) wrote: > > The SQL spec doesn't define row-level security, and coming > > up with something willy-nilly on our own doesn't really strike me as the > > best approach. > > Exactly. But there is plenty of discussion on that elsewhere. That's the nice thing about the SE-PostgreSQL patch.. It's at least following established row-level security setups in other enterprise RDBMSs... The folks coming out now and saying we should require using a WHERE clause or similar would cause a serious deviation from what's being done today, without any real change or advantage that I see.. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] 8.4 release planning
Peter Eisentraut writes: > Not to pick on you personally, but this is the kind of review that should > have > happened six months ago, not during a "why is our development process > inadequate" discussion on the eve of beta. Right now, today, in this thread, is the first time that we've had any opportunity to debate the design of SEPostgres with knowledgeable people other than KaiGai-san. It would likely be better if we started a new thread with a more appropriate title, but I see nothing wrong with asking pretty fundamental questions. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On Tuesday 27 January 2009 19:10:40 Gregory Stark wrote: > It does seem weird to simply omit records rather than throw an error and > require the user to use a where clause, even if it's something like WHERE > pg_accessible(tab). Not to pick on you personally, but this is the kind of review that should have happened six months ago, not during a "why is our development process inadequate" discussion on the eve of beta. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Tom Lane wrote:
Ron Mayer writes:
It seems to me that there are two different standards to which this feature
might be held.
Is the goal
a) SEPostgres can provide useful rules to add security to some
specific applications so long as you're careful to avoid crafting
policies that produce bizarre behaviors (like avoiding restricing
access to foreign key data you might need). On the other hand it
gives you enough rope to hang yourself and produce weird results
that don't make sense from a SQL standard point of view if you
aren't careful matching the SEPostgres rules with your apps.
or
b) SEPostgreSQL should only give enough rope that you can not
craft rules that produce unexpected behavior from a SQL point
of view; and that it would be bad if one can produce SEPostgres
policies that produce unexpected SQL behavior.
With my other hat on (the red one) what I'm concerned about is whether
this patch will ever produce a feature that I could turn on in the
standard Red Hat/Fedora build of Postgres. Right at the moment it seems
that the potential performance hit, for users who are *not using*
SEPostgres but merely have to use a build in which it is present,
might be bad enough to guarantee that that will never happen.
According to the comments in security/sepgsql/core.c:
/*
* sepgsqlIsEnabled
*
* This function returns the state of SE-PostgreSQL when PGACE hooks
* are invoked, to prevent to call sepgsql() functions when
* SE-PostgreSQL is disabled.
*
* We can config the state of SE-PostgreSQL in $PGDATA/postgresql.conf.
* The GUC option "sepostgresql" can have the following four parameter.
*
* - default: It always follows the in-kernel SELinux state. When it
*works in Enforcing mode, SE-PostgreSQL also works in
*Enforcing mode. Changes of in-kernel state are delivered
*to userspace SE-PostgreSQL soon, and SELinux state
*monitoring process updates it rapidly.
* - enforcing : It always works in Enforcing mode. In-kernel SELinux
*has to be enabled.
* - permissive : It always works in Permissive mode. In-kernel SELinux
*has to be enabled.
* - disabled : It disables SE-PostgreSQL feature. It works as if
*original PostgreSQL
*/
and in the hooks there is a pgace_feature that turns off the checks:
void
pgaceGramAlterRelation(Relation rel, HeapTuple tuple, DefElem *defel)
{
switch (pgace_feature)
{
#ifdef HAVE_SELINUX
case PGACE_FEATURE_SELINUX:
if (sepgsqlIsEnabled())
{
sepgsqlGramAlterRelation(rel, tuple, defel);
return;
}
break;
#endif
default:
break;
}
if (defel)
ereport(ERROR,
(errcode(ERRCODE_PGACE_ERROR),
errmsg("unable to set security attribute of
table "
"via ALTER TABLE")));
}
So the pgace_feature turns off the backend call, there is an extra function
call, and a branch but that shouldn't cause the kind of performance degradation
you are talking about.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
Ron Mayer writes: > Tom Lane wrote: >> This seems to me to be exactly parallel to deciding that SELinux should >> control only table/column permissions within SQL; an approach that would >> be enormously less controversial, less expensive, and more reliable than >> what SEPostgres tries to do. > With the table/column approach, could users who needed some row-level > capabilities work around this easily by setting table-level access > control on partitions? Yeah, the same thing had just occurred to me. We currently throw an error if a user doesn't have permissions on every partition (child table), but perhaps that behavior could be adjusted. Ignoring unreadable children would provide behavior pretty similar to that proposed by SEPostgres. To some extent that just postpones the semantic pain until the day when we try to do unique and FK constraints that span partitions. However, I think (after only minimal thought) that that will only re-introduce the covert-channel issue, which Joshua has already stated to be acceptable. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
