From jg97986@sac.sfbay.sun.com Mon Jun 23 08:06:08 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5NF68xB004255 for ; Mon, 23 Jun 2008 08:06:08 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5NF65iD051432; Mon, 23 Jun 2008 09:06:07 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2X0070X8M53H00@brm-avmta-1.central.sun.com>; Mon, 23 Jun 2008 09:06:05 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2X0037M8M3IE50@brm-avmta-1.central.sun.com>; Mon, 23 Jun 2008 09:06:03 -0600 (MDT) Received: from sac.sfbay.sun.com (new-sac.SFBay.Sun.COM [129.146.175.65]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5NF63OQ019925; Mon, 23 Jun 2008 08:06:03 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5NF605x004250; Mon, 23 Jun 2008 08:06:00 -0700 (PDT) Received: (from jg97986@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id m5NF60VX004246; Mon, 23 Jun 2008 08:06:00 -0700 (PDT) Date: Mon, 23 Jun 2008 08:06:00 -0700 (PDT) From: James Gates Subject: Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions [LSARC/2008/394 FastTrack timeout 07/01/2008] To: lsarc-ext@sun.com Message-id: <200806231506.m5NF60VX004246@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 11578 Template Version: @(#)sac_nextcase 1.66 04/17/08 SMI This information is Copyright 2008 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions 1.2. Name of Document Author/Supplier: Author: Satyanarayana Bodapati 1.3 Date of This Document: 23 June, 2008 4. Technical Description This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Slony-1 - Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions 1.2. Name of Document Author/Supplier: Satyanarayana Bodapati 1.3. Date of This Document: 2008-06-17 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The Community you expect to review your project: Databases 1.4.2. The ARC(s) you expect to review your project: LSARC 1.5. Email Aliases: 1.5.1. Responsible Manager: Masood Mortazavi 1.5.2. Responsible Engineer: Satya Narayana 1.5.3. Marketing Manager: Rebecca Hansen 1.5.4. Interest List: databases-discuss@sun.com postgresql-techteam@sun.com sun-postgres-pteam@sun.com 2. Project Summary 2.1. Project Description: Slony-I is a "master to multiple slaves" replication system supporting cascading and failover.It is used as replication service for PostgreSQL Database. This project aims to provide Slony-I as a part of the Solaris and OpenSolaris distribution(s). This project qualifies for micro/patch release binding 2.2. Risks and Assumptions: It is assumed that porting the Slony1 to Solaris may cause modifications of the Slony1 code so that it will run properly on the Solaris platform. The modifications (if any) are expected to be minor. 3. Business Summary 3.2. Market/Requester: Slony-I is requirement from the Databases P-Team. Also requested by BBC and TJAT. 4. Technical Description: 4.1. Details: Slony-I is a "master to multiple slaves" replication system supporting cascading and failover.This can be used as replication service for PostgreSQL database.It can be started and stopped on an existing database without the need for a dump/reload cycle. It can be used for 24X7 uptime and workload distribution. 4.5. Interfaces: Slony is a replication software that strongly depends on a specific version of the PostgreSQL RDBMS. As such, the slony libraries will be placed in the same directory tree as the corresponding PostgreSQL version. It is an OSS project, not controlled by Sun, so interface stability can't be guaranteed. Exported interfaces: Interface Stability Comments ------------------------------------------------------------------------ SUNWslony1 Committed Package name SUNWpostgr-82-slony Committed Package name SUNWpostgr-83-slony Committed Package name SUNWslony1-SMF Committed Package name /usr/postgres/slony Committed Installation dir /usr/postgres/slony/* Uncommitted Slony product files /usr/postgres/8.x/lib/slony1_funcs.so Uncommitted PostgreSQL version dependent library /usr/postgres/8.x/lib/xxid.so Uncommitted PostgreSQL version dependent library /var/slony/ Committed Default data dir /var/slony/slon.conf Committed Default config file Imported interfaces: Interface Stability Comments ----------------------------------------------------------------------- /usr/postgres/8.2/lib Committed LSARC/2006/655 /usr/postgres/8.3/lib Committed LSARC/2008/004 4.9. I18N/L10N Impact: The messages produced by Slony are not localized.The locale used is always en_US. 4.10 Packaging & Delivery Slony built with particular PostgreSQL Version, works with only that PostgreSQL version ,i.e. slony built on PostgreSQL 8.2 works only against PostgreSQL 8.2 as it needs PostgreSQL 8.2 libraries. So we need to have different slony packages for each PostgreSQL version. The packaging structure is as below. We have a single package SUNWslony1 which has common files to all Slony versions and version dependent packages like SUNWpostgr-83-slony,SUNWpostgr-82-slony which contains the version dependent libraries. SUNWslony1 (common files) /usr/postgres/slony/bin/slon /usr/postgres/slony/bin/slonik /usr/postgres/slony/bin/slony_logshipper /usr/postgres/slony/share/slony1_base.sql /usr/postgres/slony/share/slony1_base.v74.sql /usr/postgres/slony/share/slony1_base.v80.sql /usr/postgres/slony/share/slony1_base.v81.sql /usr/postgres/slony/share/slony1_funcs.sql /usr/postgres/slony/share/slony1_funcs.v74.sql /usr/postgres/slony/share/slony1_funcs.v80.sql /usr/postgres/slony/share/slony1_funcs.v81.sql /usr/postgres/slony/share/xxid.v74.sql /usr/postgres/slony/share/xxid.v80.sql /usr/postgres/slony/share/xxid.v81.sql /usr/postgres/slony/share/slon-tools.pm /usr/postgres/slony/etc/slon_tools.conf-sample /usr/postgres/slony/bin/slon_kill* /usr/postgres/slony/bin/slon_start* /usr/postgres/slony/bin/slon_watchdog* /usr/postgres/slony/bin/slon_watchdog2* /usr/postgres/slony/bin/slonik_build_env* /usr/postgres/slony/bin/slonik_create_set* /usr/postgres/slony/bin/slonik_drop_node* /usr/postgres/slony/bin/slonik_drop_set* /usr/postgres/slony/bin/slonik_drop_table* /usr/postgres/slony/bin/slonik_execute_script* /usr/postgres/slony/bin/slonik_failover* /usr/postgres/slony/bin/slonik_init_cluster* /usr/postgres/slony/bin/slonik_merge_sets* /usr/postgres/slony/bin/slonik_move_set* /usr/postgres/slony/bin/slonik_print_preamble* /usr/postgres/slony/bin/slonik_restart_node* /usr/postgres/slony/bin/slonik_store_node* /usr/postgres/slony/bin/slonik_subscribe_set* /usr/postgres/slony/bin/slonik_uninstall_nodes* /usr/postgres/slony/bin/slonik_unsubscribe_set* /usr/postgres/slony/bin/slonik_update_nodes* /usr/postgres/slony/bin/slony_show_configuration* /usr/postgres/slony/man/man1/slon.1 /usr/postgres/slony/man/man1/slonik.1 /usr/postgres/slony/man/man7/admin_conninfo.7 /usr/postgres/slony/man/man7/cluster_name.7 /usr/postgres/slony/man/man7/create_set.7 /usr/postgres/slony/man/man7/define.7 /usr/postgres/slony/man/man7/drop_listen.7 /usr/postgres/slony/man/man7/drop_node.7 /usr/postgres/slony/man/man7/drop_path.7 /usr/postgres/slony/man/man7/drop_set.7 /usr/postgres/slony/man/man7/drop_trigger.7 /usr/postgres/slony/man/man7/echo.7 /usr/postgres/slony/man/man7/execute_script.7 /usr/postgres/slony/man/man7/exit.7 /usr/postgres/slony/man/man7/failover.7 /usr/postgres/slony/man/man7/include.7 /usr/postgres/slony/man/man7/init_cluster.7 /usr/postgres/slony/man/man7/lock_set.7 /usr/postgres/slony/man/man7/merge_____set.7 /usr/postgres/slony/man/man7/move_set.7 /usr/postgres/slony/man/man7/repair_config.7 /usr/postgres/slony/man/man7/restart_node.7 /usr/postgres/slony/man/man7/set_add_sequence.7 /usr/postgres/slony/man/man7/set_add_table.7 /usr/postgres/slony/man/man7/set_drop_sequence.7 /usr/postgres/slony/man/man7/set_drop_table.7 /usr/postgres/slony/man/man7/set_move_____table.7 /usr/postgres/slony/man/man7/set_move_sequence.7 /usr/postgres/slony/man/man7/sleep.7 /usr/postgres/slony/man/man7/store_____path.7 /usr/postgres/slony/man/man7/store_listen.7 /usr/postgres/slony/man/man7/store_node.7 /usr/postgres/slony/man/man7/store_trigger.7 /usr/postgres/slony/man/man7/subscribe_set.7 /usr/postgres/slony/man/man7/sync.7 /usr/postgres/slony/man/man7/table_add_key.7 /usr/postgres/slony/man/man7/uninstall_node.7 /usr/postgres/slony/man/man7/unlock_set.7 /usr/postgres/slony/man/man7/unsubscribe_set.7 /usr/postgres/slony/man/man7/update_functions.7 /usr/postgres/slony/man/man7/wait_for_event.7 SUNWpostgr-83-slony(slony libraries for PostGres 8.3) /usr/postgres/8.3/lib/xxid.so /usr/postgres/8.3/lib/slony1_funcs.so SUNWpostgr-82-slony (slony libraries for PostGres 8.2) /usr/postgres/8.2/lib/xxid.so /usr/postgres/8.2/lib/slony1_funcs.so SUNWslony-SMF (SMF package for slony) /var/svc/manifest/application/database/slony/slony.xml /lib/svc/method/slony /var/slony/ - default data directory for slony /var/slony/slon.conf - default location for slony configuration file The SMF Package for slony starts,stop,refresh a SLON daemon. Runs slony as postgres user. Properties to be defined by svcprop command: config_file - configuration file for slon daemon data_dir - data directory for storing pid file, log files cluster_name - name of the cluster (default slony_cluster) conn_info - connection info for slon daemon (default is 'host=localhost dbname=postgres user=postgres port=5432') After providing the above parameters the user can do svcadm slony start This starts the slon daemon which is responsible for managing replication activity for that node by sending/receiving the configuration events across the cluster. svcadm slony stop This stops the slon deamon which inturn stops the replication of the node. svcadm slony refresh This stops and starts slon daemon which allows the slon daemon to start with new parameters if changed in the configuration file. Slony package updates are released only for the latest PostgreSQL version. 4.11. Security Impact Slony communicates to other nodes by using PostgreSQL libpq library and can be used with or without SSL.By default postgres clients(slony nodes) can only establish local Unix Domain Socket connections, and they have to change the configuration file to open up access further. 4.12. Dependencies: Package SUNWslony1: SUNWperl584core Perl 5.8.4 programming language (core) Package SUNWpostgr-82-slony: SUNWslony1 Slony-I PostgreSQL replication system SUNWpostgr-82-server PostgreSQL 8.3 database server SUNWpostgr-82-libs PostgreSQL 8.3 client libraries Package SUNWpostgr-83-slony: SUNWslony1 Slony-I PostgreSQL replication system SUNWpostgr-83-server PostgreSQL 8.3 database server SUNWpostgr-83-libs PostgreSQL 8.3 client libraries Package SUNWslony1-SMF: SUNWslony1 Slony-I PostgreSQL replication system 5. Reference Documents: Project Site: http://www.slony.info/ LSARC/2008/004 "Integrate PostgreSQL version 8.3 into Solaris" 6. Resources and Schedule: 6.1. Projected Availability: Q4FY08 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: SFW 6.5. ARC review type: FastTrack 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: sfw 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From james.gates@sun.com Mon Jun 23 08:12:54 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5NFCsei004305 for ; Mon, 23 Jun 2008 08:12:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5NFCo9h054346 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 23 Jun 2008 09:12:54 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2X00D178XHF300@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 23 Jun 2008 08:12:53 -0700 (PDT) Received: from dm-uk-01.uk.sun.com ([129.156.101.115]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2X005538XFW1F0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 23 Jun 2008 08:12:51 -0700 (PDT) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5NFCnaD013104; Mon, 23 Jun 2008 16:12:49 +0100 (BST) Received: from [192.168.1.100] (vpn-129-150-65-217.East.Sun.COM [129.150.65.217]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with ESMTP id m5NFCTnL018302; Mon, 23 Jun 2008 16:12:38 +0100 (BST) Date: Mon, 23 Jun 2008 11:11:46 -0400 From: James Gates Subject: LSARC/2008/394 Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions [LSARC/2008/394 FastTrack timeout 07/01/2008]] To: lsarc-ext@sun.com Cc: Satya.Bn@sun.com Message-id: <485FBD32.8010908@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_4zRsLvKJTTQGHBUO0crvcQ)" X-Accept-Language: en-us, en X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509 Status: RO Content-Length: 11640 This is a multi-part message in MIME format. --Boundary_(ID_4zRsLvKJTTQGHBUO0crvcQ) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT I'm sponsoring this case for Satya. Timer expires on 1st July. Attached is a copy of the proposal, which can also be found in the case directory. -- Jim Gates Sun Microsystems Nashua, USA http://sun.com/postgresql --Boundary_(ID_4zRsLvKJTTQGHBUO0crvcQ) Content-type: text/plain; name=slony_onepager_new.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=slony_onepager_new.txt This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Slony-1 - Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions 1.2. Name of Document Author/Supplier: Satyanarayana Bodapati 1.3. Date of This Document: 2008-06-17 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The Community you expect to review your project: Databases 1.4.2. The ARC(s) you expect to review your project: LSARC 1.5. Email Aliases: 1.5.1. Responsible Manager: Masood Mortazavi 1.5.2. Responsible Engineer: Satya Narayana 1.5.3. Marketing Manager: Rebecca Hansen 1.5.4. Interest List: databases-discuss@sun.com postgresql-techteam@sun.com sun-postgres-pteam@sun.com 2. Project Summary 2.1. Project Description: Slony-I is a "master to multiple slaves" replication system supporting cascading and failover.It is used as replication service for PostgreSQL Database. This project aims to provide Slony-I as a part of the Solaris and OpenSolaris distribution(s). This project qualifies for micro/patch release binding 2.2. Risks and Assumptions: It is assumed that porting the Slony1 to Solaris may cause modifications of the Slony1 code so that it will run properly on the Solaris platform. The modifications (if any) are expected to be minor. 3. Business Summary 3.2. Market/Requester: Slony-I is requirement from the Databases P-Team. Also requested by BBC and TJAT. 4. Technical Description: 4.1. Details: Slony-I is a "master to multiple slaves" replication system supporting cascading and failover.This can be used as replication service for PostgreSQL database.It can be started and stopped on an existing database without the need for a dump/reload cycle. It can be used for 24X7 uptime and workload distribution. 4.5. Interfaces: Slony is a replication software that strongly depends on a specific version of the PostgreSQL RDBMS. As such, the slony libraries will be placed in the same directory tree as the corresponding PostgreSQL version. It is an OSS project, not controlled by Sun, so interface stability can't be guaranteed. Exported interfaces: Interface Stability Comments ------------------------------------------------------------------------ SUNWslony1 Committed Package name SUNWpostgr-82-slony Committed Package name SUNWpostgr-83-slony Committed Package name SUNWslony1-SMF Committed Package name /usr/postgres/slony Committed Installation dir /usr/postgres/slony/* Uncommitted Slony product files /usr/postgres/8.x/lib/slony1_funcs.so Uncommitted PostgreSQL version dependent library /usr/postgres/8.x/lib/xxid.so Uncommitted PostgreSQL version dependent library /var/slony/ Committed Default data dir /var/slony/slon.conf Committed Default config file Imported interfaces: Interface Stability Comments ----------------------------------------------------------------------- /usr/postgres/8.2/lib Committed LSARC/2006/655 /usr/postgres/8.3/lib Committed LSARC/2008/004 4.9. I18N/L10N Impact: The messages produced by Slony are not localized.The locale used is always en_US. 4.10 Packaging & Delivery Slony built with particular PostgreSQL Version, works with only that PostgreSQL version ,i.e. slony built on PostgreSQL 8.2 works only against PostgreSQL 8.2 as it needs PostgreSQL 8.2 libraries. So we need to have different slony packages for each PostgreSQL version. The packaging structure is as below. We have a single package SUNWslony1 which has common files to all Slony versions and version dependent packages like SUNWpostgr-83-slony,SUNWpostgr-82-slony which contains the version dependent libraries. SUNWslony1 (common files) /usr/postgres/slony/bin/slon /usr/postgres/slony/bin/slonik /usr/postgres/slony/bin/slony_logshipper /usr/postgres/slony/share/slony1_base.sql /usr/postgres/slony/share/slony1_base.v74.sql /usr/postgres/slony/share/slony1_base.v80.sql /usr/postgres/slony/share/slony1_base.v81.sql /usr/postgres/slony/share/slony1_funcs.sql /usr/postgres/slony/share/slony1_funcs.v74.sql /usr/postgres/slony/share/slony1_funcs.v80.sql /usr/postgres/slony/share/slony1_funcs.v81.sql /usr/postgres/slony/share/xxid.v74.sql /usr/postgres/slony/share/xxid.v80.sql /usr/postgres/slony/share/xxid.v81.sql /usr/postgres/slony/share/slon-tools.pm /usr/postgres/slony/etc/slon_tools.conf-sample /usr/postgres/slony/bin/slon_kill* /usr/postgres/slony/bin/slon_start* /usr/postgres/slony/bin/slon_watchdog* /usr/postgres/slony/bin/slon_watchdog2* /usr/postgres/slony/bin/slonik_build_env* /usr/postgres/slony/bin/slonik_create_set* /usr/postgres/slony/bin/slonik_drop_node* /usr/postgres/slony/bin/slonik_drop_set* /usr/postgres/slony/bin/slonik_drop_table* /usr/postgres/slony/bin/slonik_execute_script* /usr/postgres/slony/bin/slonik_failover* /usr/postgres/slony/bin/slonik_init_cluster* /usr/postgres/slony/bin/slonik_merge_sets* /usr/postgres/slony/bin/slonik_move_set* /usr/postgres/slony/bin/slonik_print_preamble* /usr/postgres/slony/bin/slonik_restart_node* /usr/postgres/slony/bin/slonik_store_node* /usr/postgres/slony/bin/slonik_subscribe_set* /usr/postgres/slony/bin/slonik_uninstall_nodes* /usr/postgres/slony/bin/slonik_unsubscribe_set* /usr/postgres/slony/bin/slonik_update_nodes* /usr/postgres/slony/bin/slony_show_configuration* /usr/postgres/slony/man/man1/slon.1 /usr/postgres/slony/man/man1/slonik.1 /usr/postgres/slony/man/man7/admin_conninfo.7 /usr/postgres/slony/man/man7/cluster_name.7 /usr/postgres/slony/man/man7/create_set.7 /usr/postgres/slony/man/man7/define.7 /usr/postgres/slony/man/man7/drop_listen.7 /usr/postgres/slony/man/man7/drop_node.7 /usr/postgres/slony/man/man7/drop_path.7 /usr/postgres/slony/man/man7/drop_set.7 /usr/postgres/slony/man/man7/drop_trigger.7 /usr/postgres/slony/man/man7/echo.7 /usr/postgres/slony/man/man7/execute_script.7 /usr/postgres/slony/man/man7/exit.7 /usr/postgres/slony/man/man7/failover.7 /usr/postgres/slony/man/man7/include.7 /usr/postgres/slony/man/man7/init_cluster.7 /usr/postgres/slony/man/man7/lock_set.7 /usr/postgres/slony/man/man7/merge_____set.7 /usr/postgres/slony/man/man7/move_set.7 /usr/postgres/slony/man/man7/repair_config.7 /usr/postgres/slony/man/man7/restart_node.7 /usr/postgres/slony/man/man7/set_add_sequence.7 /usr/postgres/slony/man/man7/set_add_table.7 /usr/postgres/slony/man/man7/set_drop_sequence.7 /usr/postgres/slony/man/man7/set_drop_table.7 /usr/postgres/slony/man/man7/set_move_____table.7 /usr/postgres/slony/man/man7/set_move_sequence.7 /usr/postgres/slony/man/man7/sleep.7 /usr/postgres/slony/man/man7/store_____path.7 /usr/postgres/slony/man/man7/store_listen.7 /usr/postgres/slony/man/man7/store_node.7 /usr/postgres/slony/man/man7/store_trigger.7 /usr/postgres/slony/man/man7/subscribe_set.7 /usr/postgres/slony/man/man7/sync.7 /usr/postgres/slony/man/man7/table_add_key.7 /usr/postgres/slony/man/man7/uninstall_node.7 /usr/postgres/slony/man/man7/unlock_set.7 /usr/postgres/slony/man/man7/unsubscribe_set.7 /usr/postgres/slony/man/man7/update_functions.7 /usr/postgres/slony/man/man7/wait_for_event.7 SUNWpostgr-83-slony(slony libraries for PostGres 8.3) /usr/postgres/8.3/lib/xxid.so /usr/postgres/8.3/lib/slony1_funcs.so SUNWpostgr-82-slony (slony libraries for PostGres 8.2) /usr/postgres/8.2/lib/xxid.so /usr/postgres/8.2/lib/slony1_funcs.so SUNWslony-SMF (SMF package for slony) /var/svc/manifest/application/database/slony/slony.xml /lib/svc/method/slony /var/slony/ - default data directory for slony /var/slony/slon.conf - default location for slony configuration file The SMF Package for slony starts,stop,refresh a SLON daemon. Runs slony as postgres user. Properties to be defined by svcprop command: config_file - configuration file for slon daemon data_dir - data directory for storing pid file, log files cluster_name - name of the cluster (default slony_cluster) conn_info - connection info for slon daemon (default is 'host=localhost dbname=postgres user=postgres port=5432') After providing the above parameters the user can do svcadm slony start This starts the slon daemon which is responsible for managing replication activity for that node by sending/receiving the configuration events across the cluster. svcadm slony stop This stops the slon deamon which inturn stops the replication of the node. svcadm slony refresh This stops and starts slon daemon which allows the slon daemon to start with new parameters if changed in the configuration file. Slony package updates are released only for the latest PostgreSQL version. 4.11. Security Impact Slony communicates to other nodes by using PostgreSQL libpq library and can be used with or without SSL.By default postgres clients(slony nodes) can only establish local Unix Domain Socket connections, and they have to change the configuration file to open up access further. 4.12. Dependencies: Package SUNWslony1: SUNWperl584core Perl 5.8.4 programming language (core) Package SUNWpostgr-82-slony: SUNWslony1 Slony-I PostgreSQL replication system SUNWpostgr-82-server PostgreSQL 8.3 database server SUNWpostgr-82-libs PostgreSQL 8.3 client libraries Package SUNWpostgr-83-slony: SUNWslony1 Slony-I PostgreSQL replication system SUNWpostgr-83-server PostgreSQL 8.3 database server SUNWpostgr-83-libs PostgreSQL 8.3 client libraries Package SUNWslony1-SMF: SUNWslony1 Slony-I PostgreSQL replication system 5. Reference Documents: Project Site: http://www.slony.info/ LSARC/2008/004 "Integrate PostgreSQL version 8.3 into Solaris" 6. Resources and Schedule: 6.1. Projected Availability: Q4FY08 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: SFW 6.5. ARC review type: FastTrack --Boundary_(ID_4zRsLvKJTTQGHBUO0crvcQ)-- From james.gates@sun.com Mon Jun 23 08:12:54 2008 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5NFCsei004305 for ; Mon, 23 Jun 2008 08:12:54 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5NFCo9h054346 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 23 Jun 2008 09:12:54 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2X00D178XHF300@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 23 Jun 2008 08:12:53 -0700 (PDT) Received: from dm-uk-01.uk.sun.com ([129.156.101.115]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2X005538XFW1F0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 23 Jun 2008 08:12:51 -0700 (PDT) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5NFCnaD013104; Mon, 23 Jun 2008 16:12:49 +0100 (BST) Received: from [192.168.1.100] (vpn-129-150-65-217.East.Sun.COM [129.150.65.217]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with ESMTP id m5NFCTnL018302; Mon, 23 Jun 2008 16:12:38 +0100 (BST) Date: Mon, 23 Jun 2008 11:11:46 -0400 From: James Gates Subject: LSARC/2008/394 Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions [LSARC/2008/394 FastTrack timeout 07/01/2008]] To: lsarc-ext@sun.com Cc: Satya.Bn@sun.com Message-id: <485FBD32.8010908@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_4zRsLvKJTTQGHBUO0crvcQ)" X-Accept-Language: en-us, en X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509 Status: RO Content-Length: 11640 This is a multi-part message in MIME format. --Boundary_(ID_4zRsLvKJTTQGHBUO0crvcQ) Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT I'm sponsoring this case for Satya. Timer expires on 1st July. Attached is a copy of the proposal, which can also be found in the case directory. -- Jim Gates Sun Microsystems Nashua, USA http://sun.com/postgresql --Boundary_(ID_4zRsLvKJTTQGHBUO0crvcQ) Content-type: text/plain; name=slony_onepager_new.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=slony_onepager_new.txt This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Slony-1 - Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions 1.2. Name of Document Author/Supplier: Satyanarayana Bodapati 1.3. Date of This Document: 2008-06-17 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The Community you expect to review your project: Databases 1.4.2. The ARC(s) you expect to review your project: LSARC 1.5. Email Aliases: 1.5.1. Responsible Manager: Masood Mortazavi 1.5.2. Responsible Engineer: Satya Narayana 1.5.3. Marketing Manager: Rebecca Hansen 1.5.4. Interest List: databases-discuss@sun.com postgresql-techteam@sun.com sun-postgres-pteam@sun.com 2. Project Summary 2.1. Project Description: Slony-I is a "master to multiple slaves" replication system supporting cascading and failover.It is used as replication service for PostgreSQL Database. This project aims to provide Slony-I as a part of the Solaris and OpenSolaris distribution(s). This project qualifies for micro/patch release binding 2.2. Risks and Assumptions: It is assumed that porting the Slony1 to Solaris may cause modifications of the Slony1 code so that it will run properly on the Solaris platform. The modifications (if any) are expected to be minor. 3. Business Summary 3.2. Market/Requester: Slony-I is requirement from the Databases P-Team. Also requested by BBC and TJAT. 4. Technical Description: 4.1. Details: Slony-I is a "master to multiple slaves" replication system supporting cascading and failover.This can be used as replication service for PostgreSQL database.It can be started and stopped on an existing database without the need for a dump/reload cycle. It can be used for 24X7 uptime and workload distribution. 4.5. Interfaces: Slony is a replication software that strongly depends on a specific version of the PostgreSQL RDBMS. As such, the slony libraries will be placed in the same directory tree as the corresponding PostgreSQL version. It is an OSS project, not controlled by Sun, so interface stability can't be guaranteed. Exported interfaces: Interface Stability Comments ------------------------------------------------------------------------ SUNWslony1 Committed Package name SUNWpostgr-82-slony Committed Package name SUNWpostgr-83-slony Committed Package name SUNWslony1-SMF Committed Package name /usr/postgres/slony Committed Installation dir /usr/postgres/slony/* Uncommitted Slony product files /usr/postgres/8.x/lib/slony1_funcs.so Uncommitted PostgreSQL version dependent library /usr/postgres/8.x/lib/xxid.so Uncommitted PostgreSQL version dependent library /var/slony/ Committed Default data dir /var/slony/slon.conf Committed Default config file Imported interfaces: Interface Stability Comments ----------------------------------------------------------------------- /usr/postgres/8.2/lib Committed LSARC/2006/655 /usr/postgres/8.3/lib Committed LSARC/2008/004 4.9. I18N/L10N Impact: The messages produced by Slony are not localized.The locale used is always en_US. 4.10 Packaging & Delivery Slony built with particular PostgreSQL Version, works with only that PostgreSQL version ,i.e. slony built on PostgreSQL 8.2 works only against PostgreSQL 8.2 as it needs PostgreSQL 8.2 libraries. So we need to have different slony packages for each PostgreSQL version. The packaging structure is as below. We have a single package SUNWslony1 which has common files to all Slony versions and version dependent packages like SUNWpostgr-83-slony,SUNWpostgr-82-slony which contains the version dependent libraries. SUNWslony1 (common files) /usr/postgres/slony/bin/slon /usr/postgres/slony/bin/slonik /usr/postgres/slony/bin/slony_logshipper /usr/postgres/slony/share/slony1_base.sql /usr/postgres/slony/share/slony1_base.v74.sql /usr/postgres/slony/share/slony1_base.v80.sql /usr/postgres/slony/share/slony1_base.v81.sql /usr/postgres/slony/share/slony1_funcs.sql /usr/postgres/slony/share/slony1_funcs.v74.sql /usr/postgres/slony/share/slony1_funcs.v80.sql /usr/postgres/slony/share/slony1_funcs.v81.sql /usr/postgres/slony/share/xxid.v74.sql /usr/postgres/slony/share/xxid.v80.sql /usr/postgres/slony/share/xxid.v81.sql /usr/postgres/slony/share/slon-tools.pm /usr/postgres/slony/etc/slon_tools.conf-sample /usr/postgres/slony/bin/slon_kill* /usr/postgres/slony/bin/slon_start* /usr/postgres/slony/bin/slon_watchdog* /usr/postgres/slony/bin/slon_watchdog2* /usr/postgres/slony/bin/slonik_build_env* /usr/postgres/slony/bin/slonik_create_set* /usr/postgres/slony/bin/slonik_drop_node* /usr/postgres/slony/bin/slonik_drop_set* /usr/postgres/slony/bin/slonik_drop_table* /usr/postgres/slony/bin/slonik_execute_script* /usr/postgres/slony/bin/slonik_failover* /usr/postgres/slony/bin/slonik_init_cluster* /usr/postgres/slony/bin/slonik_merge_sets* /usr/postgres/slony/bin/slonik_move_set* /usr/postgres/slony/bin/slonik_print_preamble* /usr/postgres/slony/bin/slonik_restart_node* /usr/postgres/slony/bin/slonik_store_node* /usr/postgres/slony/bin/slonik_subscribe_set* /usr/postgres/slony/bin/slonik_uninstall_nodes* /usr/postgres/slony/bin/slonik_unsubscribe_set* /usr/postgres/slony/bin/slonik_update_nodes* /usr/postgres/slony/bin/slony_show_configuration* /usr/postgres/slony/man/man1/slon.1 /usr/postgres/slony/man/man1/slonik.1 /usr/postgres/slony/man/man7/admin_conninfo.7 /usr/postgres/slony/man/man7/cluster_name.7 /usr/postgres/slony/man/man7/create_set.7 /usr/postgres/slony/man/man7/define.7 /usr/postgres/slony/man/man7/drop_listen.7 /usr/postgres/slony/man/man7/drop_node.7 /usr/postgres/slony/man/man7/drop_path.7 /usr/postgres/slony/man/man7/drop_set.7 /usr/postgres/slony/man/man7/drop_trigger.7 /usr/postgres/slony/man/man7/echo.7 /usr/postgres/slony/man/man7/execute_script.7 /usr/postgres/slony/man/man7/exit.7 /usr/postgres/slony/man/man7/failover.7 /usr/postgres/slony/man/man7/include.7 /usr/postgres/slony/man/man7/init_cluster.7 /usr/postgres/slony/man/man7/lock_set.7 /usr/postgres/slony/man/man7/merge_____set.7 /usr/postgres/slony/man/man7/move_set.7 /usr/postgres/slony/man/man7/repair_config.7 /usr/postgres/slony/man/man7/restart_node.7 /usr/postgres/slony/man/man7/set_add_sequence.7 /usr/postgres/slony/man/man7/set_add_table.7 /usr/postgres/slony/man/man7/set_drop_sequence.7 /usr/postgres/slony/man/man7/set_drop_table.7 /usr/postgres/slony/man/man7/set_move_____table.7 /usr/postgres/slony/man/man7/set_move_sequence.7 /usr/postgres/slony/man/man7/sleep.7 /usr/postgres/slony/man/man7/store_____path.7 /usr/postgres/slony/man/man7/store_listen.7 /usr/postgres/slony/man/man7/store_node.7 /usr/postgres/slony/man/man7/store_trigger.7 /usr/postgres/slony/man/man7/subscribe_set.7 /usr/postgres/slony/man/man7/sync.7 /usr/postgres/slony/man/man7/table_add_key.7 /usr/postgres/slony/man/man7/uninstall_node.7 /usr/postgres/slony/man/man7/unlock_set.7 /usr/postgres/slony/man/man7/unsubscribe_set.7 /usr/postgres/slony/man/man7/update_functions.7 /usr/postgres/slony/man/man7/wait_for_event.7 SUNWpostgr-83-slony(slony libraries for PostGres 8.3) /usr/postgres/8.3/lib/xxid.so /usr/postgres/8.3/lib/slony1_funcs.so SUNWpostgr-82-slony (slony libraries for PostGres 8.2) /usr/postgres/8.2/lib/xxid.so /usr/postgres/8.2/lib/slony1_funcs.so SUNWslony-SMF (SMF package for slony) /var/svc/manifest/application/database/slony/slony.xml /lib/svc/method/slony /var/slony/ - default data directory for slony /var/slony/slon.conf - default location for slony configuration file The SMF Package for slony starts,stop,refresh a SLON daemon. Runs slony as postgres user. Properties to be defined by svcprop command: config_file - configuration file for slon daemon data_dir - data directory for storing pid file, log files cluster_name - name of the cluster (default slony_cluster) conn_info - connection info for slon daemon (default is 'host=localhost dbname=postgres user=postgres port=5432') After providing the above parameters the user can do svcadm slony start This starts the slon daemon which is responsible for managing replication activity for that node by sending/receiving the configuration events across the cluster. svcadm slony stop This stops the slon deamon which inturn stops the replication of the node. svcadm slony refresh This stops and starts slon daemon which allows the slon daemon to start with new parameters if changed in the configuration file. Slony package updates are released only for the latest PostgreSQL version. 4.11. Security Impact Slony communicates to other nodes by using PostgreSQL libpq library and can be used with or without SSL.By default postgres clients(slony nodes) can only establish local Unix Domain Socket connections, and they have to change the configuration file to open up access further. 4.12. Dependencies: Package SUNWslony1: SUNWperl584core Perl 5.8.4 programming language (core) Package SUNWpostgr-82-slony: SUNWslony1 Slony-I PostgreSQL replication system SUNWpostgr-82-server PostgreSQL 8.3 database server SUNWpostgr-82-libs PostgreSQL 8.3 client libraries Package SUNWpostgr-83-slony: SUNWslony1 Slony-I PostgreSQL replication system SUNWpostgr-83-server PostgreSQL 8.3 database server SUNWpostgr-83-libs PostgreSQL 8.3 client libraries Package SUNWslony1-SMF: SUNWslony1 Slony-I PostgreSQL replication system 5. Reference Documents: Project Site: http://www.slony.info/ LSARC/2008/004 "Integrate PostgreSQL version 8.3 into Solaris" 6. Resources and Schedule: 6.1. Projected Availability: Q4FY08 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: SFW 6.5. ARC review type: FastTrack --Boundary_(ID_4zRsLvKJTTQGHBUO0crvcQ)-- From carlsonj@phorcys.east.sun.com Mon Jun 23 08:25:20 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5NFPJeT004450 for ; Mon, 23 Jun 2008 08:25:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5NFPCZC017978; Mon, 23 Jun 2008 16:25:16 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2X00L0T9I1SX00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 23 Jun 2008 08:25:13 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2X00CTE9HYZA90@nwk-avmta-1.sfbay.Sun.COM>; Mon, 23 Jun 2008 08:25:11 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5NFPA41009557; Mon, 23 Jun 2008 11:25:10 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5NFPAh1009554; Mon, 23 Jun 2008 11:25:10 -0400 (EDT) Date: Mon, 23 Jun 2008 11:25:10 -0400 From: James Carlson Subject: Re: LSARC/2008/394 Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions [LSARC/2008/394 FastTrack timeout 07/01/2008]] In-reply-to: <485FBD32.8010908@sun.com> To: James Gates Cc: lsarc-ext@sun.com, Satya.Bn@sun.com Message-id: <18527.49238.633514.61512@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <485FBD32.8010908@sun.com> Status: RO Content-Length: 956 James Gates writes: > Slony is a replication software that strongly depends on a > specific version of the PostgreSQL RDBMS. As such, > the slony libraries will be placed in the same directory tree > as the corresponding PostgreSQL version. It is an OSS project, > not controlled by Sun, so interface stability can't > be guaranteed. Using per-version file paths probably makes sense for the libraries, but does embedding under /usr/postgres make sense for the rest of it, particularly for the man pages? Burying the man paths rather than delivering to a common directory seems to make it harder to use. > /usr/postgres/slony/share/slony1_base.sql What does "share" mean again? :-/ -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Mon Jun 23 08:25:20 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5NFPJeT004450 for ; Mon, 23 Jun 2008 08:25:19 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5NFPCZC017978; Mon, 23 Jun 2008 16:25:16 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2X00L0T9I1SX00@nwk-avmta-1.sfbay.Sun.COM>; Mon, 23 Jun 2008 08:25:13 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2X00CTE9HYZA90@nwk-avmta-1.sfbay.Sun.COM>; Mon, 23 Jun 2008 08:25:11 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5NFPA41009557; Mon, 23 Jun 2008 11:25:10 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5NFPAh1009554; Mon, 23 Jun 2008 11:25:10 -0400 (EDT) Date: Mon, 23 Jun 2008 11:25:10 -0400 From: James Carlson Subject: Re: LSARC/2008/394 Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions [LSARC/2008/394 FastTrack timeout 07/01/2008]] In-reply-to: <485FBD32.8010908@sun.com> To: James Gates Cc: lsarc-ext@sun.com, Satya.Bn@sun.com Message-id: <18527.49238.633514.61512@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <485FBD32.8010908@sun.com> Status: RO Content-Length: 956 James Gates writes: > Slony is a replication software that strongly depends on a > specific version of the PostgreSQL RDBMS. As such, > the slony libraries will be placed in the same directory tree > as the corresponding PostgreSQL version. It is an OSS project, > not controlled by Sun, so interface stability can't > be guaranteed. Using per-version file paths probably makes sense for the libraries, but does embedding under /usr/postgres make sense for the rest of it, particularly for the man pages? Burying the man paths rather than delivering to a common directory seems to make it harder to use. > /usr/postgres/slony/share/slony1_base.sql What does "share" mean again? :-/ -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From james.gates@sun.com Mon Jun 23 14:58:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5NLwOfE017159 for ; Mon, 23 Jun 2008 14:58:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5NLwLlG014763 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 23 Jun 2008 22:58:23 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2X00601RPAEI00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 23 Jun 2008 14:58:22 -0700 (PDT) Received: from dm-uk-01.uk.sun.com ([129.156.101.115]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2X00LJDRP9WJ90@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 23 Jun 2008 14:58:21 -0700 (PDT) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5NLwHkB013934; Mon, 23 Jun 2008 22:58:17 +0100 (BST) Received: from [192.168.1.100] (vpn-129-150-64-243.East.Sun.COM [129.150.64.243]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with ESMTP id m5NLvx56024633; Mon, 23 Jun 2008 22:58:08 +0100 (BST) Date: Mon, 23 Jun 2008 17:57:19 -0400 From: James Gates Subject: Re: LSARC/2008/394 Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions [LSARC/2008/394 FastTrack timeout 07/01/2008]] In-reply-to: <18527.49238.633514.61512@gargle.gargle.HOWL> To: James Carlson Cc: lsarc-ext@sun.com, Satya.Bn@sun.com Message-id: <48601C3F.6090806@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.4.1.325704 References: <485FBD32.8010908@sun.com> <18527.49238.633514.61512@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509 Status: RO Content-Length: 2191 James Carlson wrote: > James Gates writes: > >> Slony is a replication software that strongly depends on a >> specific version of the PostgreSQL RDBMS. As such, >> the slony libraries will be placed in the same directory tree >> as the corresponding PostgreSQL version. It is an OSS project, >> not controlled by Sun, so interface stability can't >> be guaranteed. > > > Using per-version file paths probably makes sense for the libraries, > but does embedding under /usr/postgres make sense for the rest of it, > particularly for the man pages? Burying the man paths rather than > delivering to a common directory seems to make it harder to use. You have a good point - Slony is not on the default PATH or MANPATH. This is clearly an ease of use issue. But I'm not sure we want Slony to be easy to use for people who have no knowledge of the PostgreSQL directory hierarchy. From what I recall, it was decided to locate the generic Slony files here because Slony is an 'addition' to the PostgreSQL product. In isolation Slony is useless. It needs PostgreSQL to operate and only operates on PostgreSQL. Without having /usr/postgres/x.x/bin in your PATH, Slony won't work correctly (which implies you already know about the /usr/postgres directory). So a certain level of "knowledge" is expected in the Slony user. But since we don't have to accommodate multiple versions of Slony, we could locate the man pages in /usr/share/man (we would just need to supply --mandir=/usr/share/man to 'configure'). > > >> /usr/postgres/slony/share/slony1_base.sql > > > What does "share" mean again? :-/ > Typically "share" directories are used for architecture independent (shared) files. In this case SQL scripts. Did you have an issue with this location? The location of these files can be set with the --datadir= configure option. But "share" really is the only suitable sub directory for these SQL files. None of the other directories are suitable. Slony only has the hierarchy: / bin etc lib man share -- Jim Gates Sun Microsystems Nashua, USA http://sun.com/postgresql From james.gates@sun.com Mon Jun 23 14:58:24 2008 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5NLwOfE017159 for ; Mon, 23 Jun 2008 14:58:24 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id m5NLwLlG014763 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Mon, 23 Jun 2008 22:58:23 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2X00601RPAEI00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 23 Jun 2008 14:58:22 -0700 (PDT) Received: from dm-uk-01.uk.sun.com ([129.156.101.115]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2X00LJDRP9WJ90@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Mon, 23 Jun 2008 14:58:21 -0700 (PDT) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-01.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5NLwHkB013934; Mon, 23 Jun 2008 22:58:17 +0100 (BST) Received: from [192.168.1.100] (vpn-129-150-64-243.East.Sun.COM [129.150.64.243]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with ESMTP id m5NLvx56024633; Mon, 23 Jun 2008 22:58:08 +0100 (BST) Date: Mon, 23 Jun 2008 17:57:19 -0400 From: James Gates Subject: Re: LSARC/2008/394 Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions [LSARC/2008/394 FastTrack timeout 07/01/2008]] In-reply-to: <18527.49238.633514.61512@gargle.gargle.HOWL> To: James Carlson Cc: lsarc-ext@sun.com, Satya.Bn@sun.com Message-id: <48601C3F.6090806@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.4.1.325704 References: <485FBD32.8010908@sun.com> <18527.49238.633514.61512@gargle.gargle.HOWL> User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509 Status: RO Content-Length: 2191 James Carlson wrote: > James Gates writes: > >> Slony is a replication software that strongly depends on a >> specific version of the PostgreSQL RDBMS. As such, >> the slony libraries will be placed in the same directory tree >> as the corresponding PostgreSQL version. It is an OSS project, >> not controlled by Sun, so interface stability can't >> be guaranteed. > > > Using per-version file paths probably makes sense for the libraries, > but does embedding under /usr/postgres make sense for the rest of it, > particularly for the man pages? Burying the man paths rather than > delivering to a common directory seems to make it harder to use. You have a good point - Slony is not on the default PATH or MANPATH. This is clearly an ease of use issue. But I'm not sure we want Slony to be easy to use for people who have no knowledge of the PostgreSQL directory hierarchy. From what I recall, it was decided to locate the generic Slony files here because Slony is an 'addition' to the PostgreSQL product. In isolation Slony is useless. It needs PostgreSQL to operate and only operates on PostgreSQL. Without having /usr/postgres/x.x/bin in your PATH, Slony won't work correctly (which implies you already know about the /usr/postgres directory). So a certain level of "knowledge" is expected in the Slony user. But since we don't have to accommodate multiple versions of Slony, we could locate the man pages in /usr/share/man (we would just need to supply --mandir=/usr/share/man to 'configure'). > > >> /usr/postgres/slony/share/slony1_base.sql > > > What does "share" mean again? :-/ > Typically "share" directories are used for architecture independent (shared) files. In this case SQL scripts. Did you have an issue with this location? The location of these files can be set with the --datadir= configure option. But "share" really is the only suitable sub directory for these SQL files. None of the other directories are suitable. Slony only has the hierarchy: / bin etc lib man share -- Jim Gates Sun Microsystems Nashua, USA http://sun.com/postgresql From carlsonj@phorcys.east.sun.com Tue Jun 24 06:18:17 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5ODIHwZ009532 for ; Tue, 24 Jun 2008 06:18:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5ODI9uE007192; Tue, 24 Jun 2008 06:18:09 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2Y0050HYA8Q500@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Jun 2008 06:18:08 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2Y005RYYA7GI00@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Jun 2008 06:18:07 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5ODI7uS001453; Tue, 24 Jun 2008 09:18:07 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5ODI7Jl001450; Tue, 24 Jun 2008 09:18:07 -0400 (EDT) Date: Tue, 24 Jun 2008 09:18:06 -0400 From: James Carlson Subject: Re: LSARC/2008/394 Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions [LSARC/2008/394 FastTrack timeout 07/01/2008]] In-reply-to: <48601C3F.6090806@sun.com> To: James Gates Cc: lsarc-ext@sun.com, Satya.Bn@sun.com Message-id: <18528.62478.999504.56154@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <485FBD32.8010908@sun.com> <18527.49238.633514.61512@gargle.gargle.HOWL> <48601C3F.6090806@sun.com> Status: RO Content-Length: 2405 James Gates writes: > But since we don't have to accommodate multiple versions of Slony, we > could locate the man pages in /usr/share/man (we would just need to > supply --mandir=/usr/share/man to 'configure'). OK; that'd help. > >> /usr/postgres/slony/share/slony1_base.sql > > > > > > What does "share" mean again? :-/ > > > Typically "share" directories are used for architecture independent > (shared) files. In this case SQL scripts. > > Did you have an issue with this location? Yes. My rather oblique comment was apparently missed here. The reason /usr/share exists is that it can be a mount point for shared (i.e., NFS) data. Thus, the right way to use 'share' is to create a subdirectory under that one special mount point (such as /usr/share/foo/) rather than creating your own /usr/foo/share/ off in the hinterlands. The result of having multiple 'share' distinct directories would be absurd; you'd be asking administrators to set up each one as a separate mount point, which of course they're not going to do. It's essentially the same reason why you shouldn't create "/foo/usr" but instead "/usr/foo", or why you shouldn't have "/foo/etc" but instead "/etc/foo". The apparent desire among those creating their own private file system hierarchy is to "isolate" the subsystem from everything else. I'm asserting that this desire itself is incorrect; the software should be integrated using the system's file system semantics, not in opposition. Without the chance of a separate mount point, the meaning is just plain lost, which is why I wrote that comment. The 'share' directory turns into a cargo cult. We ship these directories hoping that the planes will return. > / > bin > etc > lib > man > share The rest is probably a bit wobbly (a private xxx/etc? what's wrong with /etc and how is /etc writable in a zone?), but that 'share' is just plain wrong, no matter how many others may have been led down this path or how strongly autoconf believes in it. In the grand scheme of things, I suppose it doesn't matter (what's one more mistaken directory in a sea of others?), but as a review comment: don't do that. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From carlsonj@phorcys.east.sun.com Tue Jun 24 06:18:17 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m5ODIHwZ009532 for ; Tue, 24 Jun 2008 06:18:17 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m5ODI9uE007192; Tue, 24 Jun 2008 06:18:09 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K2Y0050HYA8Q500@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Jun 2008 06:18:08 -0700 (PDT) Received: from phorcys.east.sun.com ([129.148.174.143]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K2Y005RYYA7GI00@nwk-avmta-2.sfbay.sun.com>; Tue, 24 Jun 2008 06:18:07 -0700 (PDT) Received: from phorcys.east.sun.com (localhost [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id m5ODI7uS001453; Tue, 24 Jun 2008 09:18:07 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id m5ODI7Jl001450; Tue, 24 Jun 2008 09:18:07 -0400 (EDT) Date: Tue, 24 Jun 2008 09:18:06 -0400 From: James Carlson Subject: Re: LSARC/2008/394 Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions [LSARC/2008/394 FastTrack timeout 07/01/2008]] In-reply-to: <48601C3F.6090806@sun.com> To: James Gates Cc: lsarc-ext@sun.com, Satya.Bn@sun.com Message-id: <18528.62478.999504.56154@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <485FBD32.8010908@sun.com> <18527.49238.633514.61512@gargle.gargle.HOWL> <48601C3F.6090806@sun.com> x_sac_archived: LSARC/2008/394 Status: RO Content-Length: 2405 James Gates writes: > But since we don't have to accommodate multiple versions of Slony, we > could locate the man pages in /usr/share/man (we would just need to > supply --mandir=/usr/share/man to 'configure'). OK; that'd help. > >> /usr/postgres/slony/share/slony1_base.sql > > > > > > What does "share" mean again? :-/ > > > Typically "share" directories are used for architecture independent > (shared) files. In this case SQL scripts. > > Did you have an issue with this location? Yes. My rather oblique comment was apparently missed here. The reason /usr/share exists is that it can be a mount point for shared (i.e., NFS) data. Thus, the right way to use 'share' is to create a subdirectory under that one special mount point (such as /usr/share/foo/) rather than creating your own /usr/foo/share/ off in the hinterlands. The result of having multiple 'share' distinct directories would be absurd; you'd be asking administrators to set up each one as a separate mount point, which of course they're not going to do. It's essentially the same reason why you shouldn't create "/foo/usr" but instead "/usr/foo", or why you shouldn't have "/foo/etc" but instead "/etc/foo". The apparent desire among those creating their own private file system hierarchy is to "isolate" the subsystem from everything else. I'm asserting that this desire itself is incorrect; the software should be integrated using the system's file system semantics, not in opposition. Without the chance of a separate mount point, the meaning is just plain lost, which is why I wrote that comment. The 'share' directory turns into a cargo cult. We ship these directories hoping that the planes will return. > / > bin > etc > lib > man > share The rest is probably a bit wobbly (a private xxx/etc? what's wrong with /etc and how is /etc writable in a zone?), but that 'share' is just plain wrong, no matter how many others may have been led down this path or how strongly autoconf believes in it. In the grand scheme of things, I suppose it doesn't matter (what's one more mistaken directory in a sea of others?), but as a review comment: don't do that. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Satya.Bn@sun.com Tue Jul 8 03:22:59 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m68AMwA6020218 for ; Tue, 8 Jul 2008 03:22:58 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m68AMqNR004721 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 8 Jul 2008 18:22:57 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3O00M03NI6YB00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 08 Jul 2008 03:22:54 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3O00K7HNI5LL50@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 08 Jul 2008 03:22:54 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m68ANvTl022452 for ; Tue, 08 Jul 2008 10:23:57 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K3O00401NCUCF00@mail-apac.sun.com> (original mail from Satya.Bn@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 08 Jul 2008 18:22:24 +0800 (SGT) Received: from [129.158.251.200] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K3O0070INHBUHGD@mail-apac.sun.com>; Tue, 08 Jul 2008 18:22:24 +0800 (SGT) Date: Tue, 08 Jul 2008 15:52:46 +0530 From: Satya Subject: Re: LSARC/2008/394 Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions [LSARC/2008/394 FastTrack timeout 07/01/2008]] In-reply-to: <18528.62478.999504.56154@gargle.gargle.HOWL> Sender: Satya.Bn@sun.com To: James Carlson Cc: James Gates , lsarc-ext@sun.com Message-id: <48733FF6.5080107@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_OI7THC5oS6yTHUYqMGu1lA)" X-PMX-Version: 5.4.1.325704 References: <485FBD32.8010908@sun.com> <18527.49238.633514.61512@gargle.gargle.HOWL> <48601C3F.6090806@sun.com> <18528.62478.999504.56154@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 17830 This is a multi-part message in MIME format. --Boundary_(ID_OI7THC5oS6yTHUYqMGu1lA) Content-type: multipart/alternative; boundary="Boundary_(ID_d093OcQmorHB5jYhw7VUgQ)" --Boundary_(ID_d093OcQmorHB5jYhw7VUgQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi James, I have updated the one-pager. Please let me know your comments. Thanks, Satya James Carlson wrote: > James Gates writes: > >> But since we don't have to accommodate multiple versions of Slony, we >> could locate the man pages in /usr/share/man (we would just need to >> supply --mandir=/usr/share/man to 'configure'). >> > > OK; that'd help. > > >>>> /usr/postgres/slony/share/slony1_base.sql >>>> >>> What does "share" mean again? :-/ >>> >>> >> Typically "share" directories are used for architecture independent >> (shared) files. In this case SQL scripts. >> >> Did you have an issue with this location? >> > > Yes. My rather oblique comment was apparently missed here. > > The reason /usr/share exists is that it can be a mount point for > shared (i.e., NFS) data. Thus, the right way to use 'share' is to > create a subdirectory under that one special mount point (such as > /usr/share/foo/) rather than creating your own /usr/foo/share/ off in > the hinterlands. The result of having multiple 'share' distinct > directories would be absurd; you'd be asking administrators to set up > each one as a separate mount point, which of course they're not going > to do. > > It's essentially the same reason why you shouldn't create "/foo/usr" > but instead "/usr/foo", or why you shouldn't have "/foo/etc" but > instead "/etc/foo". The apparent desire among those creating their > own private file system hierarchy is to "isolate" the subsystem from > everything else. I'm asserting that this desire itself is incorrect; > the software should be integrated using the system's file system > semantics, not in opposition. > > Without the chance of a separate mount point, the meaning is just > plain lost, which is why I wrote that comment. The 'share' directory > turns into a cargo cult. We ship these directories hoping that the > planes will return. > > >> / >> bin >> etc >> lib >> man >> share >> > > The rest is probably a bit wobbly (a private xxx/etc? what's wrong > with /etc and how is /etc writable in a zone?), but that > 'share' is just plain wrong, no matter how many others may have been > led down this path or how strongly autoconf believes in it. > > In the grand scheme of things, I suppose it doesn't matter (what's one > more mistaken directory in a sea of others?), but as a review comment: > don't do that. > > --Boundary_(ID_d093OcQmorHB5jYhw7VUgQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi James,

    I have updated the one-pager. Please let me know your comments.

Thanks,
Satya
   
James Carlson wrote: 
James Gates writes:
  
But since we don't have to accommodate multiple versions of Slony, we 
could locate the man pages in /usr/share/man (we would just need to 
supply --mandir=/usr/share/man to 'configure').
    

OK; that'd help.

  
	 /usr/postgres/slony/share/slony1_base.sql
        
What does "share" mean again?  :-/

      
Typically "share" directories are used for architecture independent 
(shared) files. In this case SQL scripts.

Did you have an issue with this location?
    

Yes.  My rather oblique comment was apparently missed here.

The reason /usr/share exists is that it can be a mount point for
shared (i.e., NFS) data.  Thus, the right way to use 'share' is to
create a subdirectory under that one special mount point (such as
/usr/share/foo/) rather than creating your own /usr/foo/share/ off in
the hinterlands.  The result of having multiple 'share' distinct
directories would be absurd; you'd be asking administrators to set up
each one as a separate mount point, which of course they're not going
to do.

It's essentially the same reason why you shouldn't create "/foo/usr"
but instead "/usr/foo", or why you shouldn't have "/foo/etc" but
instead "/etc/foo".  The apparent desire among those creating their
own private file system hierarchy is to "isolate" the subsystem from
everything else.  I'm asserting that this desire itself is incorrect;
the software should be integrated using the system's file system
semantics, not in opposition.

Without the chance of a separate mount point, the meaning is just
plain lost, which is why I wrote that comment.  The 'share' directory
turns into a cargo cult.  We ship these directories hoping that the
planes will return.

  
<PREFIX>/
   bin
   etc
   lib
   man
   share
    

The rest is probably a bit wobbly (a private xxx/etc? what's wrong
with /etc and how is <PREFIX>/etc writable in a zone?), but that
'share' is just plain wrong, no matter how many others may have been
led down this path or how strongly autoconf believes in it.

In the grand scheme of things, I suppose it doesn't matter (what's one
more mistaken directory in a sea of others?), but as a review comment:
don't do that.

--Boundary_(ID_d093OcQmorHB5jYhw7VUgQ)-- --Boundary_(ID_OI7THC5oS6yTHUYqMGu1lA) Content-type: text/plain; name=slony_onepager_new.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=slony_onepager_new.txt This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Slony-1 - Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions 1.2. Name of Document Author/Supplier: Satyanarayana Bodapati 1.3. Date of This Document: 2008-06-17 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The Community you expect to review your project: Databases 1.4.2. The ARC(s) you expect to review your project: LSARC 1.5. Email Aliases: 1.5.1. Responsible Manager: Masood Mortazavi 1.5.2. Responsible Engineer: Satya Narayana 1.5.3. Marketing Manager: Rebecca Hansen 1.5.4. Interest List: databases-discuss@sun.com postgresql-techteam@sun.com sun-postgres-pteam@sun.com 2. Project Summary 2.1. Project Description: Slony-I is a "master to multiple slaves" replication system supporting cascading and failover.It is used as replication service for PostgreSQL Database. This project aims to provide Slony-I as a part of the Solaris and OpenSolaris distribution(s). This project qualifies for micro/patch release binding 2.2. Risks and Assumptions: It is assumed that porting the Slony1 to Solaris may cause modifications of the Slony1 code so that it will run properly on the Solaris platform. The modifications (if any) are expected to be minor. 3. Business Summary 3.2. Market/Requester: Slony-I is requirement from the Databases P-Team. Also requested by BBC and TJAT. 4. Technical Description: 4.1. Details: Slony-I is a "master to multiple slaves" replication system supporting cascading and failover.This can be used as replication service for PostgreSQL database.It can be started and stopped on an existing database without the need for a dump/reload cycle. It can be used for 24X7 uptime and workload distribution. 4.5. Interfaces: Slony is a replication software that strongly depends on a specific version of the PostgreSQL RDBMS. As such, the slony libraries will be placed in the same directory tree as the corresponding PostgreSQL version. It is an OSS project, not controlled by Sun, so interface stability can't be guaranteed. Exported interfaces: Interface Stability Comments ------------------------------------------------------------------------ SUNWslony1 Committed Package name SUNWpostgr-82-slony Committed Package name SUNWpostgr-83-slony Committed Package name SUNWslony1-SMF Committed Package name /usr/postgres/slony Committed Installation dir /usr/postgres/slony/* Uncommitted Slony product files /usr/postgres/8.x/lib/slony1_funcs.so Uncommitted PostgreSQL version dependent library /usr/postgres/8.x/lib/xxid.so Uncommitted PostgreSQL version dependent library /usr/postgres/8.x/share/slony1*.sql Uncommitted PostgreSQL version /usr/postgres/8.x/share/xxid*.sql dependent share files /usr/postgres/8.x/share/slon-tools.pm /var/slony/ Committed Default data dir for slony smf /var/slony/slon.conf Committed Default config file for slony smf /etc/slony/ Committed Default config dir for slonik scripts /etc/slony/slon_tools.conf-sample Uncommited sample config file for slonik scripts Imported interfaces: Interface Stability Comments ----------------------------------------------------------------------- /usr/postgres/8.2/lib Committed LSARC/2006/655 /usr/postgres/8.3/lib Committed LSARC/2008/004 4.9. I18N/L10N Impact: The messages produced by Slony are not localized.The locale used is always en_US. 4.10 Packaging & Delivery Slony built with particular PostgreSQL Version, works with only that PostgreSQL version ,i.e. slony built on PostgreSQL 8.2 works only against PostgreSQL 8.2 as it needs PostgreSQL 8.2 libraries. So we need to have different slony packages for each PostgreSQL version. The packaging structure is as below. We have a single package SUNWslony1 which has common files to all Slony versions and version dependent packages like SUNWpostgr-83-slony,SUNWpostgr-82-slony which contains the version dependent libraries. SUNWslony1 (common files) /usr/postgres/slony/bin/slon /usr/postgres/slony/bin/slonik /usr/postgres/slony/bin/slony_logshipper /usr/postgres/slony/bin/slon_kill* /usr/postgres/slony/bin/slon_start* /usr/postgres/slony/bin/slon_watchdog* /usr/postgres/slony/bin/slon_watchdog2* /usr/postgres/slony/bin/slonik_build_env* /usr/postgres/slony/bin/slonik_create_set* /usr/postgres/slony/bin/slonik_drop_node* /usr/postgres/slony/bin/slonik_drop_set* /usr/postgres/slony/bin/slonik_drop_table* /usr/postgres/slony/bin/slonik_execute_script* /usr/postgres/slony/bin/slonik_failover* /usr/postgres/slony/bin/slonik_init_cluster* /usr/postgres/slony/bin/slonik_merge_sets* /usr/postgres/slony/bin/slonik_move_set* /usr/postgres/slony/bin/slonik_print_preamble* /usr/postgres/slony/bin/slonik_restart_node* /usr/postgres/slony/bin/slonik_store_node* /usr/postgres/slony/bin/slonik_subscribe_set* /usr/postgres/slony/bin/slonik_uninstall_nodes* /usr/postgres/slony/bin/slonik_unsubscribe_set* /usr/postgres/slony/bin/slonik_update_nodes* /usr/postgres/slony/bin/slony_show_configuration* /etc/slony/slon_tools.conf-sample /usr/share/man/man1/slon.1 /usr/share/man/man1/slonik.1 /usr/share/man/man7/admin_conninfo.7 /usr/share/man/man7/cluster_name.7 /usr/share/man/man7/create_set.7 /usr/share/man/man7/define.7 /usr/share/man/man7/drop_listen.7 /usr/share/man/man7/drop_node.7 /usr/share/man/man7/drop_path.7 /usr/share/man/man7/drop_set.7 /usr/share/man/man7/drop_trigger.7 /usr/share/man/man7/echo.7 /usr/share/man/man7/execute_script.7 /usr/share/man/man7/exit.7 /usr/share/man/man7/failover.7 /usr/share/man/man7/include.7 /usr/share/man/man7/init_cluster.7 /usr/share/man/man7/lock_set.7 /usr/share/man/man7/merge_____set.7 /usr/share/man/man7/move_set.7 /usr/share/man/man7/repair_config.7 /usr/share/man/man7/restart_node.7 /usr/share/man/man7/set_add_sequence.7 /usr/share/man/man7/set_add_table.7 /usr/share/man/man7/set_drop_sequence.7 /usr/share/man/man7/set_drop_table.7 /usr/share/man/man7/set_move_____table.7 /usr/share/man/man7/set_move_sequence.7 /usr/share/man/man7/sleep.7 /usr/share/man/man7/store_____path.7 /usr/share/man/man7/store_listen.7 /usr/share/man/man7/store_node.7 /usr/share/man/man7/store_trigger.7 /usr/share/man/man7/subscribe_set.7 /usr/share/man/man7/sync.7 /usr/share/man/man7/table_add_key.7 /usr/share/man/man7/uninstall_node.7 /usr/share/man/man7/unlock_set.7 /usr/share/man/man7/unsubscribe_set.7 /usr/share/man/man7/update_functions.7 /usr/share/man/man7/wait_for_event.7 SUNWpostgr-83-slony(slony libraries and share files for PostGres 8.3) /usr/postgres/8.3/lib/xxid.so /usr/postgres/8.3/lib/slony1_funcs.so /usr/postgres/8.3/share/slony1_base.sql /usr/postgres/8.3/share/slony1_base.v74.sql /usr/postgres/8.3/share/slony1_base.v80.sql /usr/postgres/8.3/share/slony1_base.v81.sql /usr/postgres/8.3/share/slony1_funcs.sql /usr/postgres/8.3/share/slony1_funcs.v74.sql /usr/postgres/8.3/share/slony1_funcs.v80.sql /usr/postgres/8.3/share/slony1_funcs.v81.sql /usr/postgres/8.3/share/xxid.v74.sql /usr/postgres/8.3/share/xxid.v80.sql /usr/postgres/8.3/share/xxid.v81.sql /usr/postgres/8.3/share/slon-tools.pm SUNWpostgr-82-slony (slony libraries and share files for PostGres 8.2) /usr/postgres/8.2/lib/xxid.so /usr/postgres/8.2/lib/slony1_funcs.so /usr/postgres/8.2/share/slony1_base.sql /usr/postgres/8.2/share/slony1_base.v74.sql /usr/postgres/8.2/share/slony1_base.v80.sql /usr/postgres/8.2/share/slony1_base.v81.sql /usr/postgres/8.2/share/slony1_funcs.sql /usr/postgres/8.2/share/slony1_funcs.v74.sql /usr/postgres/8.2/share/slony1_funcs.v80.sql /usr/postgres/8.2/share/slony1_funcs.v81.sql /usr/postgres/8.2/share/xxid.v74.sql /usr/postgres/8.2/share/xxid.v80.sql /usr/postgres/8.2/share/xxid.v81.sql /usr/postgres/8.2/share/slon-tools.pm SUNWslony-SMF (SMF package for slony) /var/svc/manifest/application/database/slony/slony.xml /lib/svc/method/slony /var/slony/ - default data directory for slony /var/slony/slon.conf - default location for slony configuration file The SMF Package for slony starts,stop,refresh a SLON daemon. Runs slony as postgres user. Properties to be defined by svcprop command: config_file - configuration file for slon daemon data_dir - data directory for storing pid file, log files cluster_name - name of the cluster (default slony_cluster) conn_info - connection info for slon daemon (default is 'host=localhost dbname=postgres user=postgres port=5432') After providing the above parameters the user can do svcadm slony start This starts the slon daemon which is responsible for managing replication activity for that node by sending/receiving the configuration events across the cluster. svcadm slony stop This stops the slon deamon which inturn stops the replication of the node. svcadm slony refresh This stops and starts slon daemon which allows the slon daemon to start with new parameters if changed in the configuration file. Slony package updates are released only for the latest PostgreSQL version. 4.11. Security Impact Slony communicates to other nodes by using PostgreSQL libpq library and can be used with or without SSL.By default postgres clients(slony nodes) can only establish local Unix Domain Socket connections, and they have to change the configuration file to open up access further. 4.12. Dependencies: Package SUNWslony1: SUNWperl584core Perl 5.8.4 programming language (core) Package SUNWpostgr-82-slony: SUNWslony1 Slony-I PostgreSQL replication system SUNWpostgr-82-server PostgreSQL 8.3 database server SUNWpostgr-82-libs PostgreSQL 8.3 client libraries Package SUNWpostgr-83-slony: SUNWslony1 Slony-I PostgreSQL replication system SUNWpostgr-83-server PostgreSQL 8.3 database server SUNWpostgr-83-libs PostgreSQL 8.3 client libraries Package SUNWslony1-SMF: SUNWslony1 Slony-I PostgreSQL replication system 5. Reference Documents: Project Site: http://www.slony.info/ LSARC/2008/004 "Integrate PostgreSQL version 8.3 into Solaris" 6. Resources and Schedule: 6.1. Projected Availability: Q4FY08 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: SFW 6.5. ARC review type: FastTrack --Boundary_(ID_OI7THC5oS6yTHUYqMGu1lA)-- From Satya.Bn@sun.com Tue Jul 8 03:22:59 2008 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m68AMwA6020218 for ; Tue, 8 Jul 2008 03:22:58 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id m68AMqNR004721 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 8 Jul 2008 18:22:57 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K3O00M03NI6YB00@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 08 Jul 2008 03:22:54 -0700 (PDT) Received: from sineb-mail-2.sun.com ([192.18.19.7]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K3O00K7HNI5LL50@nwk-avmta-1.sfbay.Sun.COM> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 08 Jul 2008 03:22:54 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m68ANvTl022452 for ; Tue, 08 Jul 2008 10:23:57 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) id <0K3O00401NCUCF00@mail-apac.sun.com> (original mail from Satya.Bn@Sun.COM) for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 08 Jul 2008 18:22:24 +0800 (SGT) Received: from [129.158.251.200] by mail-apac.sun.com (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPSA id <0K3O0070INHBUHGD@mail-apac.sun.com>; Tue, 08 Jul 2008 18:22:24 +0800 (SGT) Date: Tue, 08 Jul 2008 15:52:46 +0530 From: Satya Subject: Re: LSARC/2008/394 Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions [LSARC/2008/394 FastTrack timeout 07/01/2008]] In-reply-to: <18528.62478.999504.56154@gargle.gargle.HOWL> Sender: Satya.Bn@sun.com To: James Carlson Cc: James Gates , lsarc-ext@sun.com Message-id: <48733FF6.5080107@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_OI7THC5oS6yTHUYqMGu1lA)" X-PMX-Version: 5.4.1.325704 References: <485FBD32.8010908@sun.com> <18527.49238.633514.61512@gargle.gargle.HOWL> <48601C3F.6090806@sun.com> <18528.62478.999504.56154@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.14 (X11/20080505) Status: RO Content-Length: 17830 This is a multi-part message in MIME format. --Boundary_(ID_OI7THC5oS6yTHUYqMGu1lA) Content-type: multipart/alternative; boundary="Boundary_(ID_d093OcQmorHB5jYhw7VUgQ)" --Boundary_(ID_d093OcQmorHB5jYhw7VUgQ) Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi James, I have updated the one-pager. Please let me know your comments. Thanks, Satya James Carlson wrote: > James Gates writes: > >> But since we don't have to accommodate multiple versions of Slony, we >> could locate the man pages in /usr/share/man (we would just need to >> supply --mandir=/usr/share/man to 'configure'). >> > > OK; that'd help. > > >>>> /usr/postgres/slony/share/slony1_base.sql >>>> >>> What does "share" mean again? :-/ >>> >>> >> Typically "share" directories are used for architecture independent >> (shared) files. In this case SQL scripts. >> >> Did you have an issue with this location? >> > > Yes. My rather oblique comment was apparently missed here. > > The reason /usr/share exists is that it can be a mount point for > shared (i.e., NFS) data. Thus, the right way to use 'share' is to > create a subdirectory under that one special mount point (such as > /usr/share/foo/) rather than creating your own /usr/foo/share/ off in > the hinterlands. The result of having multiple 'share' distinct > directories would be absurd; you'd be asking administrators to set up > each one as a separate mount point, which of course they're not going > to do. > > It's essentially the same reason why you shouldn't create "/foo/usr" > but instead "/usr/foo", or why you shouldn't have "/foo/etc" but > instead "/etc/foo". The apparent desire among those creating their > own private file system hierarchy is to "isolate" the subsystem from > everything else. I'm asserting that this desire itself is incorrect; > the software should be integrated using the system's file system > semantics, not in opposition. > > Without the chance of a separate mount point, the meaning is just > plain lost, which is why I wrote that comment. The 'share' directory > turns into a cargo cult. We ship these directories hoping that the > planes will return. > > >> / >> bin >> etc >> lib >> man >> share >> > > The rest is probably a bit wobbly (a private xxx/etc? what's wrong > with /etc and how is /etc writable in a zone?), but that > 'share' is just plain wrong, no matter how many others may have been > led down this path or how strongly autoconf believes in it. > > In the grand scheme of things, I suppose it doesn't matter (what's one > more mistaken directory in a sea of others?), but as a review comment: > don't do that. > > --Boundary_(ID_d093OcQmorHB5jYhw7VUgQ) Content-type: text/html; charset=ISO-8859-1 Content-transfer-encoding: 7BIT Hi James,

    I have updated the one-pager. Please let me know your comments.

Thanks,
Satya
   
James Carlson wrote: 
James Gates writes:
  
But since we don't have to accommodate multiple versions of Slony, we 
could locate the man pages in /usr/share/man (we would just need to 
supply --mandir=/usr/share/man to 'configure').
    

OK; that'd help.

  
	 /usr/postgres/slony/share/slony1_base.sql
        
What does "share" mean again?  :-/

      
Typically "share" directories are used for architecture independent 
(shared) files. In this case SQL scripts.

Did you have an issue with this location?
    

Yes.  My rather oblique comment was apparently missed here.

The reason /usr/share exists is that it can be a mount point for
shared (i.e., NFS) data.  Thus, the right way to use 'share' is to
create a subdirectory under that one special mount point (such as
/usr/share/foo/) rather than creating your own /usr/foo/share/ off in
the hinterlands.  The result of having multiple 'share' distinct
directories would be absurd; you'd be asking administrators to set up
each one as a separate mount point, which of course they're not going
to do.

It's essentially the same reason why you shouldn't create "/foo/usr"
but instead "/usr/foo", or why you shouldn't have "/foo/etc" but
instead "/etc/foo".  The apparent desire among those creating their
own private file system hierarchy is to "isolate" the subsystem from
everything else.  I'm asserting that this desire itself is incorrect;
the software should be integrated using the system's file system
semantics, not in opposition.

Without the chance of a separate mount point, the meaning is just
plain lost, which is why I wrote that comment.  The 'share' directory
turns into a cargo cult.  We ship these directories hoping that the
planes will return.

  
<PREFIX>/
   bin
   etc
   lib
   man
   share
    

The rest is probably a bit wobbly (a private xxx/etc? what's wrong
with /etc and how is <PREFIX>/etc writable in a zone?), but that
'share' is just plain wrong, no matter how many others may have been
led down this path or how strongly autoconf believes in it.

In the grand scheme of things, I suppose it doesn't matter (what's one
more mistaken directory in a sea of others?), but as a review comment:
don't do that.

--Boundary_(ID_d093OcQmorHB5jYhw7VUgQ)-- --Boundary_(ID_OI7THC5oS6yTHUYqMGu1lA) Content-type: text/plain; name=slony_onepager_new.txt Content-transfer-encoding: 7BIT Content-disposition: inline; filename=slony_onepager_new.txt This information is Copyright 2007 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: Slony-1 - Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions 1.2. Name of Document Author/Supplier: Satyanarayana Bodapati 1.3. Date of This Document: 2008-06-17 1.4. Name of Major Document Customer(s)/Consumer(s): 1.4.1. The Community you expect to review your project: Databases 1.4.2. The ARC(s) you expect to review your project: LSARC 1.5. Email Aliases: 1.5.1. Responsible Manager: Masood Mortazavi 1.5.2. Responsible Engineer: Satya Narayana 1.5.3. Marketing Manager: Rebecca Hansen 1.5.4. Interest List: databases-discuss@sun.com postgresql-techteam@sun.com sun-postgres-pteam@sun.com 2. Project Summary 2.1. Project Description: Slony-I is a "master to multiple slaves" replication system supporting cascading and failover.It is used as replication service for PostgreSQL Database. This project aims to provide Slony-I as a part of the Solaris and OpenSolaris distribution(s). This project qualifies for micro/patch release binding 2.2. Risks and Assumptions: It is assumed that porting the Slony1 to Solaris may cause modifications of the Slony1 code so that it will run properly on the Solaris platform. The modifications (if any) are expected to be minor. 3. Business Summary 3.2. Market/Requester: Slony-I is requirement from the Databases P-Team. Also requested by BBC and TJAT. 4. Technical Description: 4.1. Details: Slony-I is a "master to multiple slaves" replication system supporting cascading and failover.This can be used as replication service for PostgreSQL database.It can be started and stopped on an existing database without the need for a dump/reload cycle. It can be used for 24X7 uptime and workload distribution. 4.5. Interfaces: Slony is a replication software that strongly depends on a specific version of the PostgreSQL RDBMS. As such, the slony libraries will be placed in the same directory tree as the corresponding PostgreSQL version. It is an OSS project, not controlled by Sun, so interface stability can't be guaranteed. Exported interfaces: Interface Stability Comments ------------------------------------------------------------------------ SUNWslony1 Committed Package name SUNWpostgr-82-slony Committed Package name SUNWpostgr-83-slony Committed Package name SUNWslony1-SMF Committed Package name /usr/postgres/slony Committed Installation dir /usr/postgres/slony/* Uncommitted Slony product files /usr/postgres/8.x/lib/slony1_funcs.so Uncommitted PostgreSQL version dependent library /usr/postgres/8.x/lib/xxid.so Uncommitted PostgreSQL version dependent library /usr/postgres/8.x/share/slony1*.sql Uncommitted PostgreSQL version /usr/postgres/8.x/share/xxid*.sql dependent share files /usr/postgres/8.x/share/slon-tools.pm /var/slony/ Committed Default data dir for slony smf /var/slony/slon.conf Committed Default config file for slony smf /etc/slony/ Committed Default config dir for slonik scripts /etc/slony/slon_tools.conf-sample Uncommited sample config file for slonik scripts Imported interfaces: Interface Stability Comments ----------------------------------------------------------------------- /usr/postgres/8.2/lib Committed LSARC/2006/655 /usr/postgres/8.3/lib Committed LSARC/2008/004 4.9. I18N/L10N Impact: The messages produced by Slony are not localized.The locale used is always en_US. 4.10 Packaging & Delivery Slony built with particular PostgreSQL Version, works with only that PostgreSQL version ,i.e. slony built on PostgreSQL 8.2 works only against PostgreSQL 8.2 as it needs PostgreSQL 8.2 libraries. So we need to have different slony packages for each PostgreSQL version. The packaging structure is as below. We have a single package SUNWslony1 which has common files to all Slony versions and version dependent packages like SUNWpostgr-83-slony,SUNWpostgr-82-slony which contains the version dependent libraries. SUNWslony1 (common files) /usr/postgres/slony/bin/slon /usr/postgres/slony/bin/slonik /usr/postgres/slony/bin/slony_logshipper /usr/postgres/slony/bin/slon_kill* /usr/postgres/slony/bin/slon_start* /usr/postgres/slony/bin/slon_watchdog* /usr/postgres/slony/bin/slon_watchdog2* /usr/postgres/slony/bin/slonik_build_env* /usr/postgres/slony/bin/slonik_create_set* /usr/postgres/slony/bin/slonik_drop_node* /usr/postgres/slony/bin/slonik_drop_set* /usr/postgres/slony/bin/slonik_drop_table* /usr/postgres/slony/bin/slonik_execute_script* /usr/postgres/slony/bin/slonik_failover* /usr/postgres/slony/bin/slonik_init_cluster* /usr/postgres/slony/bin/slonik_merge_sets* /usr/postgres/slony/bin/slonik_move_set* /usr/postgres/slony/bin/slonik_print_preamble* /usr/postgres/slony/bin/slonik_restart_node* /usr/postgres/slony/bin/slonik_store_node* /usr/postgres/slony/bin/slonik_subscribe_set* /usr/postgres/slony/bin/slonik_uninstall_nodes* /usr/postgres/slony/bin/slonik_unsubscribe_set* /usr/postgres/slony/bin/slonik_update_nodes* /usr/postgres/slony/bin/slony_show_configuration* /etc/slony/slon_tools.conf-sample /usr/share/man/man1/slon.1 /usr/share/man/man1/slonik.1 /usr/share/man/man7/admin_conninfo.7 /usr/share/man/man7/cluster_name.7 /usr/share/man/man7/create_set.7 /usr/share/man/man7/define.7 /usr/share/man/man7/drop_listen.7 /usr/share/man/man7/drop_node.7 /usr/share/man/man7/drop_path.7 /usr/share/man/man7/drop_set.7 /usr/share/man/man7/drop_trigger.7 /usr/share/man/man7/echo.7 /usr/share/man/man7/execute_script.7 /usr/share/man/man7/exit.7 /usr/share/man/man7/failover.7 /usr/share/man/man7/include.7 /usr/share/man/man7/init_cluster.7 /usr/share/man/man7/lock_set.7 /usr/share/man/man7/merge_____set.7 /usr/share/man/man7/move_set.7 /usr/share/man/man7/repair_config.7 /usr/share/man/man7/restart_node.7 /usr/share/man/man7/set_add_sequence.7 /usr/share/man/man7/set_add_table.7 /usr/share/man/man7/set_drop_sequence.7 /usr/share/man/man7/set_drop_table.7 /usr/share/man/man7/set_move_____table.7 /usr/share/man/man7/set_move_sequence.7 /usr/share/man/man7/sleep.7 /usr/share/man/man7/store_____path.7 /usr/share/man/man7/store_listen.7 /usr/share/man/man7/store_node.7 /usr/share/man/man7/store_trigger.7 /usr/share/man/man7/subscribe_set.7 /usr/share/man/man7/sync.7 /usr/share/man/man7/table_add_key.7 /usr/share/man/man7/uninstall_node.7 /usr/share/man/man7/unlock_set.7 /usr/share/man/man7/unsubscribe_set.7 /usr/share/man/man7/update_functions.7 /usr/share/man/man7/wait_for_event.7 SUNWpostgr-83-slony(slony libraries and share files for PostGres 8.3) /usr/postgres/8.3/lib/xxid.so /usr/postgres/8.3/lib/slony1_funcs.so /usr/postgres/8.3/share/slony1_base.sql /usr/postgres/8.3/share/slony1_base.v74.sql /usr/postgres/8.3/share/slony1_base.v80.sql /usr/postgres/8.3/share/slony1_base.v81.sql /usr/postgres/8.3/share/slony1_funcs.sql /usr/postgres/8.3/share/slony1_funcs.v74.sql /usr/postgres/8.3/share/slony1_funcs.v80.sql /usr/postgres/8.3/share/slony1_funcs.v81.sql /usr/postgres/8.3/share/xxid.v74.sql /usr/postgres/8.3/share/xxid.v80.sql /usr/postgres/8.3/share/xxid.v81.sql /usr/postgres/8.3/share/slon-tools.pm SUNWpostgr-82-slony (slony libraries and share files for PostGres 8.2) /usr/postgres/8.2/lib/xxid.so /usr/postgres/8.2/lib/slony1_funcs.so /usr/postgres/8.2/share/slony1_base.sql /usr/postgres/8.2/share/slony1_base.v74.sql /usr/postgres/8.2/share/slony1_base.v80.sql /usr/postgres/8.2/share/slony1_base.v81.sql /usr/postgres/8.2/share/slony1_funcs.sql /usr/postgres/8.2/share/slony1_funcs.v74.sql /usr/postgres/8.2/share/slony1_funcs.v80.sql /usr/postgres/8.2/share/slony1_funcs.v81.sql /usr/postgres/8.2/share/xxid.v74.sql /usr/postgres/8.2/share/xxid.v80.sql /usr/postgres/8.2/share/xxid.v81.sql /usr/postgres/8.2/share/slon-tools.pm SUNWslony-SMF (SMF package for slony) /var/svc/manifest/application/database/slony/slony.xml /lib/svc/method/slony /var/slony/ - default data directory for slony /var/slony/slon.conf - default location for slony configuration file The SMF Package for slony starts,stop,refresh a SLON daemon. Runs slony as postgres user. Properties to be defined by svcprop command: config_file - configuration file for slon daemon data_dir - data directory for storing pid file, log files cluster_name - name of the cluster (default slony_cluster) conn_info - connection info for slon daemon (default is 'host=localhost dbname=postgres user=postgres port=5432') After providing the above parameters the user can do svcadm slony start This starts the slon daemon which is responsible for managing replication activity for that node by sending/receiving the configuration events across the cluster. svcadm slony stop This stops the slon deamon which inturn stops the replication of the node. svcadm slony refresh This stops and starts slon daemon which allows the slon daemon to start with new parameters if changed in the configuration file. Slony package updates are released only for the latest PostgreSQL version. 4.11. Security Impact Slony communicates to other nodes by using PostgreSQL libpq library and can be used with or without SSL.By default postgres clients(slony nodes) can only establish local Unix Domain Socket connections, and they have to change the configuration file to open up access further. 4.12. Dependencies: Package SUNWslony1: SUNWperl584core Perl 5.8.4 programming language (core) Package SUNWpostgr-82-slony: SUNWslony1 Slony-I PostgreSQL replication system SUNWpostgr-82-server PostgreSQL 8.3 database server SUNWpostgr-82-libs PostgreSQL 8.3 client libraries Package SUNWpostgr-83-slony: SUNWslony1 Slony-I PostgreSQL replication system SUNWpostgr-83-server PostgreSQL 8.3 database server SUNWpostgr-83-libs PostgreSQL 8.3 client libraries Package SUNWslony1-SMF: SUNWslony1 Slony-I PostgreSQL replication system 5. Reference Documents: Project Site: http://www.slony.info/ LSARC/2008/004 "Integrate PostgreSQL version 8.3 into Solaris" 6. Resources and Schedule: 6.1. Projected Availability: Q4FY08 6.4. Product Approval Committee requested information: 6.4.1. Consolidation or Component Name: SFW 6.5. ARC review type: FastTrack --Boundary_(ID_OI7THC5oS6yTHUYqMGu1lA)-- From james.gates@sun.com Tue Jul 15 13:22:35 2008 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id m6FKMZgL024476 for ; Tue, 15 Jul 2008 13:22:35 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6FKMZde014825 for <@sunmail2sca.sfbay.sun.com:lsarc-ext@sun.com>; Tue, 15 Jul 2008 13:22:35 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0K4200A0DDXNJF00@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 15 Jul 2008 13:22:35 -0700 (PDT) Received: from dm-uk-02.uk.sun.com ([129.156.101.196]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0K4200403DXK61A0@nwk-avmta-2.sfbay.sun.com> for lsarc-ext@sun.com (ORCPT lsarc-ext@sun.com); Tue, 15 Jul 2008 13:22:33 -0700 (PDT) Received: from serinus.UK.Sun.COM (serinus.UK.Sun.COM [129.156.173.208]) by dm-uk-02.uk.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id m6FKMVCb004452; Tue, 15 Jul 2008 21:22:31 +0100 (BST) Received: from [192.168.1.100] (vpn-129-150-65-230.East.Sun.COM [129.150.65.230]) by serinus.UK.Sun.COM (8.13.7+Sun/8.13.7/CTE 3.0) with ESMTP id m6FKMD0I026656; Tue, 15 Jul 2008 21:22:22 +0100 (BST) Date: Tue, 15 Jul 2008 16:21:25 -0400 From: James Gates Subject: LSARC case approved 07/15/2008 (2008/394) To: lsarc-ext@sun.com, Satya Message-id: <487D06C5.1010704@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en X-PMX-Version: 5.4.1.325704 User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.7.13) Gecko/20060509 Status: RO Content-Length: 499 This case is now approved following some amendments to file installation locations (on the recommendation of James Carlson). Name: Provide Slony as a replication tool for PostgreSQL on Solaris and OpenSolaris distributions Submitter: Satyanarayana Bodapati Owner: James Gates Interest: Status: closed approved fast-track 07/15/2008 Exposure: open Comment: -- Jim Gates Sun Microsystems Nashua, USA http://sun.com/postgresql