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  (Tom Lane <tgl@sss.pgh.pa.us>)
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:

Previous
From: Gregory Stark
Date:
Subject: Re: 8SEPostgres WAS: .4 release planning
Next
From: Tom Lane
Date:
Subject: Re: FK column doesn't exist error message could use more detail