EOF of PostgreSQL 8.2 in Solaris [LSARC/2008/616 timeout 10/08/2008]
James Gates
James.Gates at sun.com
Thu Oct 2 08:58:06 PDT 2008
Oh, I see. We would have to modify the community code to include a call
to syslog(3), but I don't see that as too much of a problem.
I think the biggest issue is, for S10, this can only be issued in a
patch. So we're relying on people who don't read release notes to keep
up to date with the latest patches. Therefore there's a good chance that
no one will ever see the syslog message, but since it's technically
feasible to do, we will do it.
John Fischer wrote:
> James,
>
> The application warning message would be from the previous
> release. So you would need to patch an application or applications
> with the message for Solaris 10. This should occur at the
> same time as the release notes are updated. The reason why
> this is desirable is because many of the those using the
> product might not even see the release notes or read a
> man page. That is why the EOF procedures document found
> at:
>
> http://sac.sfbay/cgi-bin/bp.cgi?NAME=Obsolete-EOF.bp
>
> suggests:
>
> Where technically feasible, inclusion in the release
> where the interface is declared Obsolete of a warning
> mechanism if the interface is used.
>
> It goes on to suggest a log warning could be used.
>
> So in the Patch release of Solaris where the release note
> will be updated it would be really good and if technically
> feasible to also have a mechanism for the EOF message to
> be declared automatically. When I've Obsoleted an interface
> I have done a popup dialog because I deal with GUIs. However,
> in this case a system log or to standard error would be sufficient.
>
> Thanks,
>
> John
>
> On Thu, 2008-10-02 at 07:14, James Gates wrote:
>> John Fischer wrote:
>>> James,
>>>
>>> Sounds like a well thought out plan.
>>>
>>> Does it make sense to add to the release note which
>>> version is recommended to migrate to in the future release?
>>> So perhaps the release note might say something like:
>>>
>>> PostgreSQL version 8.2 may no longer be supported
>>> in a future release of Solaris. You may want to
>>> migrate to PostgresSQL version 8.4.
>>>
>> That makes sense. We can even include in the message a reference to our
>> upgrade tool.
>>> Also is there a command that should spit out the same
>>> message?
>> We hadn't planned to do this.
>>
>> All the 8.2 binaries are found in /usr/postgres/8.2/bin. I had
>> anticipated that this would no longer exist after an upgrade, since all
>> 8.2 packages will be removed.
>>
>> There are 3 popular commands in /usr/postgres/8.2/bin that a user would
>> call to create, start or connect to a PostgreSQL database.
>>
>> I suppose when we remove the 8.2 packages from Nevada, we could add 3
>> scripts to /usr/postgres/8.2/bin in the 8.3 packages that print the
>> above message. And when we EOF 8.3, add similar scripts to 8.4, etc.
>>> Thanks,
>>>
>>> John
>>>
>>>
>>> On Tue, 2008-09-30 at 15:15, James Gates wrote:
>>>> I'm sponsoring this on behalf of the PostgreSQL P-Team. Timeout is set
>>>> for 8th October. Attached is a copy of the proposal, which can also be
>>>> found in the case directory.
>>>>
>>>> --
>>>> Jim Gates Sun Microsystems
>>>> Nashua, NH, USA http://sun.com/postgresql
>>>>
>>>> ______________________________________________________________________
>>>> 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.2 in Solaris
>>>>
>>>> 1.2. Name of Document Author/Supplier:
>>>> James Gates
>>>>
>>>> 1.3. Date of This Document:
>>>> 09/30/08
>>>>
>>>> 1.3.1. Date this project was conceived:
>>>> 09/17/08
>>>>
>>>> 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:
>>>>
>>>> Chris.Armes at sun.com
>>>>
>>>> 1.4.4. The name of your business unit:
>>>>
>>>> Software/RPE
>>>>
>>>> 1.5. Email Aliases:
>>>> 1.5.1. Responsible Manager: Thulasinathan.P at sun.com
>>>> 1.5.2. Responsible Engineer: James.Gates at sun.com
>>>> 1.5.3. Marketing Manager: Wei-Chen.Chiu at sun.com
>>>> 1.5.4. Interest List: sun-postgres-pteam at sun.com
>>>>
>>>> [In the following, "8.1", "8.2", "8.3" or "8.4" without qualification
>>>> refer to the corresponding PostgreSQL version.]
>>>>
>>>> 2. Project Summary
>>>> 2.1. Project Description:
>>>>
>>>> Solaris currently includes versions 8.1, 8.2 & 8.3. It is expected
>>>> that the community will release 8.4 in Dec 2008. We plan to integrate
>>>> it into Solaris shortly after community release.
>>>>
>>>> This project proposes to announce the EOF for 8.2 in a patch
>>>> release of Solaris (i.e. Solaris 10 Update) and removal of the
>>>> feature in a minor release of Solaris (i.e. Solaris 11).
>>>>
>>>> The intention of the PostgreSQL EOL policy approved by the DB PAC
>>>> is to provide active support for the latest 2 versions integrated
>>>> with Solaris. Hence the release and integration of 8.4 triggers the
>>>> EOF & EOL of 8.2.
>>>>
>>>> Note that the ARC case to EOF 8.1 was approved on 01/15/2008
>>>> (LSARC/2008/005).
>>>>
>>>> 2.2. Risks and Assumptions:
>>>>
>>>> If Solaris 11 is shipped without 8.2 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 (although I think this is unlikely).
>>>> Those customers who must continue to run 8.2 can still visit the
>>>> community website and download the freely available software.
>>>>
>>>> There is also a risk that some other Sun products depend on
>>>> 8.2; we need to ensure that these are upgraded to at least 8.3.
>>>> I have verified that no other packages in the SFWNV
>>>> consilidation are listed as depending on any of the PostgreSQL
>>>> 8.2 packages.
>>>>
>>>> 3. Business Summary
>>>>
>>>> 3.1. Problem Area:
>>>>
>>>> The PostgreSQL community release a new major version approximately
>>>> once every year. For various reasons, we need to encourage customers
>>>> to upgrade to newer versions when they become available.
>>>>
>>>> 3.2. Market/Requester:
>>>>
>>>> PostgreSQL P-Team
>>>>
>>>> 3.3. Business Justification:
>>>>
>>>> We want to reduce the amount of resources needed to support and sustain
>>>> old versions of PostgreSQL. We also want to keep in sync with the
>>>> PostgreSQL communitys EOL policy i.e. we don't want to
>>>> be in the position of having a PostgreSQL version in Solaris that is
>>>> no longer supported and maintained by the community.
>>>>
>>>> 3.4. Competitive Analysis:
>>>>
>>>> N/A
>>>>
>>>> 3.5. Opportunity Window/Exposure:
>>>>
>>>> This needs to coincide with the integration of 8.4, so as to ensure
>>>> that only the latest 2 versions of PostgreSQL are available/supported,
>>>> and all previous versions are EOF/EOL.
>>>>
>>>> 3.6. How will you know when you are done?:
>>>>
>>>> The project will be complete when the announcement is made in
>>>> a patch release of Solaris and when 8.2 is removed from a minor
>>>> release of Solaris.
>>>>
>>>> 4. Technical Description:
>>>> 4.1. Details:
>>>>
>>>> This project will create a release note in a Patch release of
>>>> Solaris (i.e. Solaris 10 Update). It will also remove all 8.2
>>>> packages from a Minor release of Solaris (i.e., Solaris 11).
>>>>
>>>> The Solaris 10 Update Release Notes will be updated with the
>>>> following text:
>>>>
>>>> PostgreSQL version 8.2 may no longer be supported
>>>> in a future release.
>>>>
>>>> 4.2. Bug/RFE Number(s):
>>>>
>>>> N/A
>>>>
>>>> 4.3. In Scope:
>>>>
>>>> 4.4. Out of Scope:
>>>>
>>>> 4.5. Interfaces:
>>>>
>>>> Imported Interfaces:
>>>> Interface Stability Citation
>>>> --------- --------- ----------
>>>> N/A
>>>>
>>>> Exported Interfaces:
>>>> Interface Classification Comments
>>>> --------------------- --------------- ------------------------
>>>> SUNWpostgr-82-client Obsolete Package
>>>> SUNWpostgr-82-contrib Obsolete Package
>>>> SUNWpostgr-82-devel Obsolete Package
>>>> SUNWpostgr-82-docs Obsolete Package
>>>> SUNWpostgr-82-jdbc Obsolete Package
>>>> SUNWpostgr-82-libs Obsolete Package
>>>> SUNWpostgr-82-pl Obsolete Package
>>>> SUNWpostgr-82-server Obsolete Package
>>>> SUNWpostgr-82-server-data-root Obsolete Package
>>>> SUNWpostgr-82-tcl Obsolete Package
>>>> /lib/svc/method/postgresql Obselete SMF method script
>>>> /usr/postgres/8.2 Obsolete Installation location
>>>> /usr/postgres/8.2/bin Obsolete Executable location
>>>> /usr/postgres/8.2/doc Obsolete Documentation
>>>> /usr/postgres/8.2/etc Obsolete Config files
>>>> /usr/postgres/8.2/include Obsolete Header files
>>>> /usr/postgres/8.2/jdbc Obsolete JDBC driver
>>>> /usr/postgres/8.2/lib Obsolete Shared libraries
>>>> /usr/postgres/8.2/man Obsolete Manual pages
>>>> /usr/postgres/8.2/share Obsolete Localized message files
>>>> /usr/share/man/man5/postgres_82.5 Obselete Sun specific man page
>>>> /var/postgres/8.2 Obselete Default db location
>>>> /var/svc/manifest/application/database/postgresql.xml Obselete SMF manifest file
>>>>
>>>> Also deleted are all files under /usr/postgres/8.2/* (too numerous to
>>>> list here).
>>>>
>>>> 4.6. Doc Impact:
>>>>
>>>> Comprehensive documentation was included with the product. This will
>>>> be removed. The only other documentation impact will be the delivery
>>>> of the release note (see section 4.1).
>>>>
>>>> 4.7. Admin/Config Impact:
>>>>
>>>> None.
>>>>
>>>> 4.8. HA Impact:
>>>>
>>>> N/A
>>>>
>>>> 4.9. I18N/L10N Impact:
>>>>
>>>> N/A
>>>>
>>>> 4.10. Packaging & Delivery:
>>>>
>>>> The packages listed in 4.5 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 or 8.2 will have to use the upgrade solution we
>>>> included with the 8.3 integration to upgrade to 8.3 or 8.4.
>>>>
>>>> 4.11. Security Impact:
>>>>
>>>> No impact.
>>>>
>>>> 4.12. Dependencies:
>>>>
>>>> Depends on the integration of 8.4
>>>>
>>>> 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:
>>>>
>>>> Can be done immediately after 8.4 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.4.
>>>>
>>>> 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
>> --
>> Jim Gates Sun Microsystems
>> Nashua, NH, USA http://sun.com/postgresql
>
--
Jim Gates Sun Microsystems
Nashua, NH, USA http://sun.com/postgresql
More information about the opensolaris-arc
mailing list