Template Version: @(#)onepager.txt 1.35 07/11/07 SMI Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: EOF of PostgreSQL 8.1 in Solaris 1.2. Name of Document Author/Supplier: Bjorn Munch 1.3. Date of This Document: 12/19/07 1.3.1. Date this project was conceived: 12/01/07 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The PAC or CPT you expect to review your project: Database PAC 1.4.2. The ARC(s) you expect to review your project: LSARC 1.4.3. The Director/VP who is "Sponsoring" this project: Heidi.Bergh-Hoff@sun.com 1.4.4. The name of your business unit: Software 1.5. Email Aliases: 1.5.1. Responsible Manager: Yngve.Svendsen@sun.com 1.5.2. Responsible Engineer: Bjorn.Munch@sun.com 1.5.3. Marketing Manager: Rebecca.Hansen@sun.com 1.5.4. Interest List: sun-postgres-pteam@sun.com 2. Project Summary 2.1. Project Description: [In the following "8.1", "8.2" or "8.3" without qualification refer to the corresponding PostgreSQL version.] In the discussions for the ARC case for integrating PostgreSQL 8.2 (LSARC/2006/655) it was suggested that if 8.3 became integrated before FCS of Solaris 11, we might EOF 8.1, provided an upgrade tool/solution is available. PostgreSQL 8.3 will soon ready to be integrated, a separate ARC has been filed for this (LSARC/2008/004) With the integration of 8.3, we will provide an upgrade solution. The exact implementation details are not finalized, but it will come in a separate package which likely will include a few binaries from 8.1 and a script. It may include separate solutions for upgrade to 8.2 and to 8.3. 2.2. Risks and Assumptions: If Solaris 11 is shipped without 8.1, it would force customers still running this version to upgrade PostgreSQL immediately if they upgrade their O/S. They might even decide not to upgrade because of this. I have no idea how many customers this might affect though, and it's not a problem for those who are already running 8.2. There is also a risk that some other Sun products depend on 8.1; we need to ensure that these are upgraded to at least 8.2. I have verified that no other packages in the SFWNV consilidation are listed as depending on any of the PostgreSQL 8.1 packages. 3. Business Summary 3.1. Problem Area: For the users, the mere existence of the 8.1 installation under the default /usr/bin path can cause problems if they really want to run a later version. They may on occation run the 8.1 version of e.g. psql (the interactive SQL client) by mistake. I have done this myself during testing. Also, since 8.1 is more "easily" available, some users starting up with PostgreSQL might pick that version instead of the latest, which is something we want to discourage. 3.2. Market/Requester: This was recommended in the discussions around the ARC case for PostgreSQL 8.2 (LSARC/2006/655). 3.3. Business Justification: We want to reduce the amount of resources needed to sustain 8.1 in the future. We also want to remove one source of potential inconvenience for users who want to run PostgreSQL 8.2 or 8.3. 3.4. Competitive Analysis: N/A 3.5. Opportunity Window/Exposure: This needs to be done after 8.3 and an upgrade solution becomes available, or at the same time. 3.6. How will you know when you are done?: When 8.1 has been removed from the SFWNV consolidation. 4. Technical Description: 4.1. Details: This project will remove the following packages: SUNWpostgr-contrib SUNWpostgr-devel SUNWpostgr-docs SUNWpostgr-jdbc SUNWpostgr-libs SUNWpostgr-pl SUNWpostgr-server SUNWpostgr-server-data SUNWpostgr-tcl 4.2. Bug/RFE Number(s): N/A 4.3. In Scope: 4.4. Out of Scope: 4.5. Interfaces: All interfaces provided by the packages listed in section 4.1 will be deleted. This includes among others, the following files: /etc/pgsql/psqlrc.sample /usr/bin/DBMirror.pl /usr/bin/clean_pending.pl /usr/bin/dbf2pg /usr/bin/ecpg /usr/bin/fti.pl /usr/bin/initdb /usr/bin/ipcclean /usr/bin/oid2name /usr/bin/pg_config /usr/bin/pg_controldata /usr/bin/pg_ctl /usr/bin/pg_resetxlog /usr/bin/pgbench /usr/bin/pltcl_delmod /usr/bin/pltcl_listmod /usr/bin/pltcl_loadmod /usr/bin/postgres /usr/bin/postmaster /usr/bin/vacuumlo /usr/include/pgsql/* /usr/share/java/postgresql.jar /usr/share/pgsql/* /var/lib/pgsql/* Also deleted are a number of files under /usr/lib, /usr/share/man, /usr/share/doc, /usr/share/locale etc. too numerous to list here. 4.6. Doc Impact: There is one Sun produced document that accompanies PostgreSQL (a small installation & configuration guide), this will be updated to remove the reference to PostgreSQL 8.1. 4.7. Admin/Config Impact: None. 4.8. HA Impact: N/A 4.9. I18N/L10N Impact: No. 4.10. Packaging & Delivery: The packages listed in 4.1 will be deleted and will not be included with the first release of Solaris 11. However, note that they have been delivered with SXDE; I don't know if this will require us to go through the full EOF process. Users upgrading from Solaris 10 who are running a database under PostgreSQL 8.1 will have to use the upgrade solution we plan to include with the 8.3 integration. 4.11. Security Impact: No impact. 4.12. Dependencies: Depends on the integration of 8.3 and an upgrade solution from 8.1 to 8.3 (or 8.2); this is being filed as a separate ARC case. 5. Reference Documents: All material associated with the original ARC case to integrate PostgreSQL 8.1 can be found at: http://sac.sfbay.sun.com/LSARC/2005/515/ Material associated with the ARC case to integrate PostgreSQL 8.2 can be found at: http://sac.sfbay.sun.com/LSARC/2006/655/ Material associated with the ARC case to integrate PostgreSQL 8.3 can be found at http://sac.sfbay.sun.com/LSARC/2008/004 PostgreSQL 8.3 information can be found at: http://www.postgresql.org/ 6. Resources and Schedule: 6.1. Projected Availability: Has a logical depencency on availability of PostgreSQL 8.3 and the upgrade tool, probably January 2008. Can be done immediately once this is integrated. 6.2. Cost of Effort: Minimal; just removal of a component. 6.3. Cost of Capital Resources: None. 6.4.1. Consolidation or Component Name: SFW 6.4.3. Type of CPT Review and Approval expected: FastTrack 6.4.4. Project Boundary Conditions: N/A 6.4.5. Is this a necessary project for OEM agreements: No 6.4.6. Notes: 6.4.7. Target RTI Date/Release: ASAP after the community releases 8.3. 6.4.8. Target Code Design Review Date: 6.4.9. Update approval addition: 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open 6.6.1. Rationale: N/A 7. Prototype Availability: 7.1. Prototype Availability: N/A 7.2. Prototype Cost: N/A