Re: 8.4 release planning - Mailing list pgsql-hackers
From | Stephen Frost |
---|---|
Subject | Re: 8.4 release planning |
Date | |
Msg-id | 20090126232325.GA8123@tamriel.snowman.net Whole thread Raw |
In response to | Re: 8.4 release planning (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: 8.4 release planning
|
List | pgsql-hackers |
* Tom Lane (tgl@sss.pgh.pa.us) wrote: > Josh Berkus <josh@agliodbs.com> writes: > > Users: care about HS more than anything else in the world. > > I don't think this is correct. There are certainly a lot of users who > would like an in-core replication solution, but HS by itself is not that > --- you also need (near) real-time log shipping, which we have already > decided to punt to 8.5. That being the case, I think the argument > that HS is a must-have feature for 8.4 is actually rather weak. HS would still be really nice, and I'm a bit concerned that we'll end up in 8.5 with a similar discussion along the lines of "well, we've only just committed HS, why don't we release 8.5 with that and wait on replication till 8.6". I agree that more folks are after replication than HS, but there is still a user base for it. > > SE-Linux: this patch has effectively been in development for 2 years > > ourside the core process before putting it in; the forked SEPostgres is > > in use in production. KaiGai has been available for 20 hours a week (or > > more) to troubleshoot issues and change APIs. I really don't see what > > the problem is with committing it. > > The problem, in words of one syllable, is that we are not sure we want > it. Do you see a user community clamoring for SEPostgres, or a hacker > community that is willing or able to maintain it? If KaiGai-san got run > over by a bus tomorrow, this patch would be a dead letter, because there > just isn't anyone else who is taking sufficient (any?) interest in it. I'm certainly interested in it and would like to see it in core. Would I use it immediately? No, because I've so far avoided having to have it for my systems. I don't expect that to last forever though, at some point I'll have to implement a system which requires the seperation provided by SELinux or move to something like Solaris Trusted Extensions and Oracle Label Security. > That doesn't bode well for its future viability. Compare the likely > audience for it to previous patches of roughly similar complexity, > such as integrated text search or the Windows port, and it's just not > in the ballpark. No, it doesn't have as large a user base as the Windows port or integrated text search. On the other hand, there *are* users out there, and hackers, who are willing and interested in it for PostgreSQL because it would give them an alternative to the de-facto standards. Perhaps it's just me, but historically it seems like there's also been a fair bit of aid given to trusted/SE implementations by various organizations who need it, both in terms of funding for others to work on it and in actual direct development. I realize this is a trivially defeated POV, but I really feel that 'if you build it, they will come' in this case. > The second problem is that we're not sure it's really the right thing, > because we have no one who is competent to review the design from a > security standpoint. But unless we get past the first problem the > second one is moot. I think the database design for SELinux is pretty well defined.. The implementation needs to be reviewed, but I think there's few who can do that, unfortunately. Thanks, Stephen
pgsql-hackers by date: