Обсуждение: PostgreSQL 7 RPMs coming soon
This is a heads up about some changes I'm considering for the PostgreSQL 7.0 RPMS. If the RPMs do not interest you, or you are not involved in supporting PostgreSQL in the RPM form, then feel free to hit delete. I wanted to get feedback from the group before I made any changes -- 7.0 is slated to go beta Feb 15, and I plan on having RPM's available within a few hours of the official beta release. I already have feedback from my contact at RedHat -- and it is complete agreement with the changes I am proposing. First, 7.0 has changed many small things about the operation of the system, including a new procedural language (plperl), a reorganized regression test suite, and a new 'pg_ctl' command to start and stop the postmaster. As a result, I will be having to make some minor changes; and there is one major change I want to make. 1.) I want to move the actual database directory from /var/lib/pgsql to /var/lib/pgsql/data -- this will give the ability to store backups and other scratch data in /var/lib/pgsql without disturbing the main database, in an FHS-compliant manner (the current regression tests AND upgrade scripts are not in compliance with the FHS in terms of their packaging, unfortunately -- I want to rectify this). This of course will require sufficient documentation -- and I will provide functionality to use an existing data structure in /var/lib/pgsql instead, until the user moves it (new installations will default the initdb to /var/lib/pgsql/data). 2.) I will be enabling logs and logrotate functionality in the next release. 3.) /etc/rc.d/init.d/postgresql will be rewritten to use the pg_ctl command, instead of doing the start/stop manually. 4.) The new plperl language will go in postgresql-perl. 5.) I am considering splitting out pgaccess and the tk client from postgresql-tcl to postgresql-tk -- I have had several requests from users of servers that are using the tcl client and the pltcl language who do not have X11 installed, a current requirement for the installation of postgresql-tcl. 6.) And, of course, an update to version 7.0. This will involve extensive testing for Alpha, Sparc, and MIPS support -- I am hoping that Ryan Kirkpatrick and Uncle George can get the Alpha patches in order for 7.0, as I don't believe Tom had time to do the fmgr rewrite like he wanted. I am also hoping that a number of people with MIPS, ARM, Alpha, and Sparc (both 32 and 64) will volunteer to beta test 7.0. The initial builds will be done for Intel only -- until I get patches and/or confirmation of build on other architectures from those who are able to test those. If you have additional suggestions for improving the RPM distribution, please e-mail them to me. TIA for your feedback. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Lamar, I got report from bulgarian user who had problem with locale under MANDRAKE caused by 'su -l postgres ...' I'll forward it to you. Incorrectly configured i18n (LC_ALL) could override (?) locale settings even if LC_CTYPE, LC_COLLATE explicitly specified in startup script. I think you could check if all locale environment are consistent with each other. Oleg On Mon, 7 Feb 2000, Lamar Owen wrote: > Date: Mon, 07 Feb 2000 12:12:22 -0500 > From: Lamar Owen <lamar.owen@wgcr.org> > To: pgsql-hackers@postgreSQL.org > Subject: [HACKERS] PostgreSQL 7 RPMs coming soon > > This is a heads up about some changes I'm considering for the PostgreSQL > 7.0 RPMS. If the RPMs do not interest you, or you are not involved in > supporting PostgreSQL in the RPM form, then feel free to hit delete. > > I wanted to get feedback from the group before I made any changes -- 7.0 > is > slated to go beta Feb 15, and I plan on having RPM's available within a > few hours of the official beta release. I already have feedback from my > contact at RedHat -- and it is complete agreement with the changes I am > proposing. > > First, 7.0 has changed many small things about the operation of the > system, including a new procedural language (plperl), a reorganized > regression test suite, and a new 'pg_ctl' command to start and stop the > postmaster. > > As a result, I will be having to make some minor changes; and there is > one major change I want to make. > > 1.) I want to move the actual database directory from /var/lib/pgsql to > /var/lib/pgsql/data -- this will give the ability to store backups and > other scratch data in /var/lib/pgsql without disturbing the main > database, in an FHS-compliant manner (the current regression tests AND > upgrade scripts are not in compliance with the FHS in terms of their > packaging, unfortunately -- I want to rectify this). This of course will > require sufficient documentation -- and I will provide functionality to > use an existing data structure in /var/lib/pgsql instead, until the user > moves it (new installations will default the initdb to > /var/lib/pgsql/data). > > 2.) I will be enabling logs and logrotate functionality in the next > release. > > 3.) /etc/rc.d/init.d/postgresql will be rewritten to use the pg_ctl > command, instead of doing the start/stop manually. > > 4.) The new plperl language will go in postgresql-perl. > > 5.) I am considering splitting out pgaccess and the tk client from > postgresql-tcl to postgresql-tk -- I have had several requests from > users of servers that are using the tcl client and the pltcl language > who do not have X11 installed, a current requirement for the > installation of postgresql-tcl. > > 6.) And, of course, an update to version 7.0. This will involve > extensive testing for Alpha, Sparc, and MIPS support -- I am hoping that > Ryan Kirkpatrick and Uncle George can get the Alpha patches in order for > 7.0, as I don't believe Tom had time to do the fmgr rewrite like he > wanted. I am also hoping that a number of people with MIPS, ARM, Alpha, > and Sparc (both 32 and 64) will volunteer to beta test 7.0. > > The initial builds will be done for Intel only -- until I get patches > and/or confirmation of build on other architectures from those who are > able to test those. > > If you have additional suggestions for improving the RPM distribution, > please e-mail them to me. > > TIA for your feedback. > > -- > Lamar Owen > WGCR Internet Radio > 1 Peter 4:11 > > ************ > _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
On 2000-02-07, Lamar Owen mentioned: > 1.) I want to move the actual database directory from /var/lib/pgsql to > /var/lib/pgsql/data -- this will give the ability to store backups and > other scratch data in /var/lib/pgsql without disturbing the main > database, in an FHS-compliant manner (the current regression tests AND > upgrade scripts are not in compliance with the FHS in terms of their > packaging, unfortunately -- I want to rectify this). This of course will > require sufficient documentation -- and I will provide functionality to > use an existing data structure in /var/lib/pgsql instead, until the user > moves it (new installations will default the initdb to > /var/lib/pgsql/data). What exactly is FHS and what do they say? I am vaguely phantasizing about doing a little work on the build process for the next release; is that something that could be addressed? -- Peter Eisentraut Sernanders väg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden
Peter Eisentraut wrote: > > database, in an FHS-compliant manner (the current regression tests AND > > upgrade scripts are not in compliance with the FHS in terms of their [snip] > What exactly is FHS and what do they say? I am vaguely phantasizing about > doing a little work on the build process for the next release; is that > something that could be addressed? FHS 2.0 is the Filesystem Hierarchy Standard, successor to the Linux FileSystem Standard (FSSTND). You may find the full document at http://www.pathname.com/fhs/ Currently, in order to get PostgreSQL into RPM form requires a number of mungifications -- the current prefix parameter is set to /usr, which puts binaries and shared libs in the right place -- but everything else is moved into place manually. It is a rather kludgy build script (ask Thomas, he knows). To look at the build script (in RPM parlance, a 'spec file'), load up http://www.ramifordistat.net/postgres/unpacked/non-beta/postgresql-6.5.3-3.spec (one line; it'll probably wrap on your e-mail client). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11
Yes, this seems very much like the stuff I've been thinking about. I'll bring it up when the next devel cycle has started. On Mon, 7 Feb 2000, Lamar Owen wrote: > Peter Eisentraut wrote: > > > database, in an FHS-compliant manner (the current regression tests AND > > > upgrade scripts are not in compliance with the FHS in terms of their > [snip] > > > What exactly is FHS and what do they say? I am vaguely phantasizing about > > doing a little work on the build process for the next release; is that > > something that could be addressed? > > FHS 2.0 is the Filesystem Hierarchy Standard, successor to the Linux > FileSystem Standard (FSSTND). You may find the full document at > http://www.pathname.com/fhs/ > > Currently, in order to get PostgreSQL into RPM form requires a number of > mungifications -- the current prefix parameter is set to /usr, which > puts binaries and shared libs in the right place -- but everything else > is moved into place manually. It is a rather kludgy build script (ask > Thomas, he knows). To look at the build script (in RPM parlance, a > 'spec file'), load up > http://www.ramifordistat.net/postgres/unpacked/non-beta/postgresql-6.5.3-3.spec > (one line; it'll probably wrap on your e-mail client). > > -- > Lamar Owen > WGCR Internet Radio > 1 Peter 4:11 > > -- Peter Eisentraut Sernanders vaeg 10:115 peter_e@gmx.net 75262 Uppsala http://yi.org/peter-e/ Sweden