On Fri, May 05, 2006 at 12:03:09AM +0200, Rainer Orth wrote: > Since I first looked into the upcoming PostgreSQL integration into Solaris, > I had a couple of issues with how this was done. Since at least one hasn't > been dealt with yet, I'd like to raise them here:
Rainer, you raise a lot of good points. It's a shame that the case log is not available, but there's a lot of ugly history here. > * As I had already commented two months ago in the only message on the > solarispackages-hackers at pgfoundry.org mailing list > > > http://lists.pgfoundry.org/pipermail/solarispackages-hackers/2006-March/000000.html > > I have some issues with the directories selected for some pgsql > components. To cite from that message: > > * Shipping many internal PostgreSQL modules directly in /usr/lib completely > clutters this directory, which should be a no-no. I think only the > libraries that represent an interface belong there. The modules rather > belong into /usr/lib/pgsql, just like /usr/lib/dns. Similarly with the host of commands that got put into /usr/bin. This was considered for a long time and with much gnashing of teeth, and the ARC case was nearly rejected because of it, but was given a one-time exemption to ship "dirty", with the expectation that it will be fixed the next time postgres is revved. The team integrating postgres asserted that there was too much work to do to make this change in the amount of time they had, and that they already had initial positive feedback from the postgres community that such a change would be welcome, and preferred to push the change that way. We'll have to see how that plays out. > * The use of /var/lib/pgsql for the the data and backups directories > seems wrong on Solaris: I can see no reason at all for having > /var/lib; this seems to be an unfortunate Linuxism that shouldn't > creep into the Solaris version. I think simply /var/pgsql would be > more appropriate here. > > /var/pgsql would also be much more in line with /var/mysql. Probably. The ARC missed that detail with all the rest of the hoopla going on. > * I noticed that currently, pgsql is statically linked against > libreadline. It would probably be very useful to provide a dynamic > libreadline, since several other programs could benefit as well, > e.g. gdb. This was a specific decision by the ARC, fearing the introduction of an attractive nuisance. Readline's license is GPL, hence it "infects" anything linking against it. This doesn't affect postgres, but would affect any project that thought they were able to link against readline. The ARC felt the reward of allowing a shared readline was not sufficient to balance the risk of projects using it inappropriately. The decision can always be revisited on its own. > * Last but not least, it would be very desirable to have at the very least > an init.d script for pgsql, but perferably convert it to an SMF service. > There's an open CR for this, too: > > 6405382 No manifest/start method included in SUNWpostgr-server > > but I have no idea who the submitter is and how far this has progressed. SMF integration was considered by the ARC, and ultimately rejected as a requirement. The ARC did avise the project team that this should be done, and that it would be a requirement at the next review. The ARC explicitly disallowed an init script, as that practice is now strongly discouraged for Sun projects (just a touch more so, the ARC believed, than SMF is encouraged). Danek
