Affected packages, all in version 8.4.1: dev-db/postgresql-base dev-db/postgresql-docs dev-db/postgresql-server Arch teams, please magic your make!
Looks like that amounts to at least these packages: =virtual/postgresql-base-8.4 =dev-db/postgresql-base-8.4.1 =dev-db/postgresql-docs-8.4.1 =dev-db/postgresql-server-8.4.1 app-admin/eselect-postgresql-0.3
reqarding postgresql...the maintainer says it should still be masked! 08:47 <@dev-zero> Elvanor: the old 8.4er is masked, or should be 08:47 <@dev-zero> in fact, it shouldn't even be there
where the "old" meant: dev-db/postgresql (as in not-splitted), so good to go
ppc64 done
Satbel on alpha.
Ok, I'm extending the packages needing to be stabled so we can finally mask libpq and the old postgresql ebuilds. For that we need one package for each of the 5 currently supported slots: =virtual/postgresql-base-{7.4,8.0,8.1,8.2,8.3,8.4} =dev-db/postgresql-base-{7.4.26,8.0.22,8.1.18,8.2.14,8.3.8,8.4.1} =dev-db/postgresql-docs-{7.4.26,8.0.22,8.1.18,8.2.14,8.3.8,8.4.1} =dev-db/postgresql-server-{7.4.26,8.0.22,8.1.18,8.2.14,8.3.8,8.4.1} app-admin/eselect-postgresql-0.3 Sorry 'bout the extra work :)
I think we might want virtual/postgresql-server as well.
(In reply to comment #6) > Ok, I'm extending the packages needing to be stabled so we can finally mask > libpq and the old postgresql ebuilds. For that we need one package for each of > the 5 currently supported slots: > > =virtual/postgresql-base-{7.4,8.0,8.1,8.2,8.3,8.4} > =dev-db/postgresql-base-{7.4.26,8.0.22,8.1.18,8.2.14,8.3.8,8.4.1} > =dev-db/postgresql-docs-{7.4.26,8.0.22,8.1.18,8.2.14,8.3.8,8.4.1} > =dev-db/postgresql-server-{7.4.26,8.0.22,8.1.18,8.2.14,8.3.8,8.4.1} > app-admin/eselect-postgresql-0.3 > > Sorry 'bout the extra work :) > So you want all those (straight to) stable?
yes, all those and virtual/postgresql-server (which I forgot, sorry)
*** Bug 230817 has been marked as a duplicate of this bug. ***
ppc stable
Created attachment 208339 [details] gdb run log Looks like it's inside the test app, not the library, but I'll let you decide what to do about it :)
Oh dear, wrong bug. Disregard comment and attachment :-/
bug 286260 can be work around...what is about bug 274836...
AMD64: I have been working with postgresql-server-8.4.1 and postgresql-base-8.4.1 for a few weeks now and no problems at all. Works like a charm! emerge --info: Portage 2.1.6.13 (default/linux/amd64/10.0/no-multilib, gcc-4.3.4, glibc-2.9_p20081201-r2, 2.6.30-gentoo-r5 x86_64) ================================================================= System uname: Linux-2.6.30-gentoo-r5-x86_64-AMD_Athlon-tm-_64_X2_Dual_Core_Processor_5200+-with-gentoo-1.12.13 Timestamp of tree: Thu, 05 Nov 2009 02:15:01 +0000 app-shells/bash: 4.0_p28 dev-lang/python: 2.6.2-r1 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 1.6-r2 sys-devel/autoconf: 2.63-r1 sys-devel/automake: 1.7.9-r1, 1.9.6-r2, 1.10.2 sys-devel/binutils: 2.18-r3 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.6a virtual/os-headers: 2.6.27-r2 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=k8 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /var/bind" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/eselect/postgresql /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-march=k8 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="collision-protect distlocks fixpackages multilib-strict parallel-fetch protect-owned sandbox sfperms strict unmerge-orphans userfetch userpriv" GENTOO_MIRRORS="http://gentoo.tiscali.nl/ ftp://gentoo.tiscali.nl/pub/mirror/gentoo/ " LANG="en_US.utf8" LDFLAGS="-Wl,-O1" LINGUAS="en" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/overlay" SYNC="rsync://rsync.tiscali.nl/gentoo-portage" USE="3dnow amd64 apache2 bash-completion bzip bzip2 caps cli cracklib crypt cue cupsddk curl dri exif flac ftp gdbm git graphviz gzip iconv icu id3 jabber jpeg json lame libsamplerate mmx mod_muc modules mp3 mudflap mysql ncurses nls nptl nptlonly ogg openmp pcre php png posix pppd readline reflection session simplexml spl sse sse2 ssl svg sysfs tcpd truetype unicode unzip vorbis web webdav xml xmlreader xmlrpc xmlwriter xorg zip zlib" ALSA_CARDS="hda-intel" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en" USERLAND="GNU" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, FFLAGS, INSTALL_MASK, LC_ALL, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Stable for HPPA.
Can we stablize this one for x86, too, please? Even though I haven't read all changelogs I wouldn't wonder if current stable version 8.1.11 has some security flaws.
I think #290535 is very easy to fix and should be fixed before stabilizing 8.4 because in the future people will start using tools like pg_migrator and if we don't switch to integer timestamps now we'll either get stuck with the old deprecated double precision timestamps or cause problems to the users of pg_migrator. Also, the elog messages about autovacuum should be changed, because now autovacuum is enabled by default. So the message "You can enable it in the clusters postgresql.conf." doesn't make sense anymore.
(In reply to comment #18) > I think #290535 is very easy to fix and should be fixed before stabilizing 8.4 > because in the future people will start using tools like pg_migrator and if we > don't switch to integer timestamps now we'll either get stuck with the old > deprecated double precision timestamps or cause problems to the users of > pg_migrator. I am hesitating to mark ebuilds stable that have problems. So, maybe you want to contact me by email so we find out what to change in the ebuild apart from the issues you talk about. I am not a user of PostgreSQL, but have commit access and interested to get it fixed.
Created attachment 212647 [details, diff] proposed changes for dev-db/postgresql-base introduces a new USE flag, pg-legacytimestamps, in place of pg-intdatetime. Their relation is pg-legacytimestamps = !pg-intdatetime. This fixes bug 290535.
Created attachment 212648 [details] proposed changes for dev-db/postgresql-server updates elog messages related to autovacuum
Created attachment 212650 [details, diff] proposed changes for dev-db/postgresql-server updates elog messages related to autovacuum
Created attachment 213060 [details, diff] proposed changes for dev-db/postgresql-base-8.4.2 introduces a new USE flag, pg-legacytimestamps, in place of pg-intdatetime. Their relation is pg-legacytimestamps = !pg-intdatetime. This fixes bug 290535.
Created attachment 213062 [details, diff] proposed changes for dev-db/postgresql-server-8.4.2 updates elog messages related to autovacuum
+ 07 Jan 2010; Patrick Lauer <patrick@gentoo.org> + +postgresql-base-8.4.2-r1.ebuild, metadata.xml: + Changing pg-intdatetime to pg_legacytimestamp useflag since upstream + changed defaults and deprecated the old behaviour. See #285475 #290535
autovacuum message fixed, thanks redneb. For stabling now please use dev-db/postgresql-base-8.4.2-r1 dev-db/postgresql-server-8.4.2-r1
(In reply to comment #25) > + 07 Jan 2010; Patrick Lauer <patrick@gentoo.org> > + +postgresql-base-8.4.2-r1.ebuild, metadata.xml: > + Changing pg-intdatetime to pg_legacytimestamp useflag since upstream > + changed defaults and deprecated the old behaviour. See #285475 #290535 > You missed an exclamation mark in the ebuild: pg_legacytimestamp is the negation of pg-intdatetime. So, in the ebuild it should be $(use_enable !pg_legacytimestamp integer-datetimes ) \ and not $(use_enable pg_legacytimestamp integer-datetimes ) \
(In reply to comment #27) > (In reply to comment #25) > > + 07 Jan 2010; Patrick Lauer <patrick@gentoo.org> > > + +postgresql-base-8.4.2-r1.ebuild, metadata.xml: > > + Changing pg-intdatetime to pg_legacytimestamp useflag since upstream > > + changed defaults and deprecated the old behaviour. See #285475 #290535 > > > > You missed an exclamation mark in the ebuild: pg_legacytimestamp is the > negation of pg-intdatetime. So, in the ebuild it should be > $(use_enable !pg_legacytimestamp integer-datetimes ) \ > and not > $(use_enable pg_legacytimestamp integer-datetimes ) \ > Oh. Yeah. Fixed, and thanks for checking :)
x86 stable
Upgrading from 8.4.2 to 8.4.2-r1 requires a full dump/initdb/restore cycle if you use the default useflags! Have tried +pg_legacytimestamp, but that does not work for whatever reason. pg_config shows the change, but the server will not start. Is't needed to set this useflag also in postgresql-server ?
amd64 stable
(In reply to comment #30) > Upgrading from 8.4.2 to 8.4.2-r1 requires a full dump/initdb/restore cycle if > you use the default useflags! Ouch, that is unexpected. > Have tried +pg_legacytimestamp, but that does not work for whatever reason. > pg_config shows the change, but the server will not start. Is't needed to set > this useflag also in postgresql-server ? The setting should get pulled in to -server through pg_config set in -base, so if you set it in -base and rebuild -base and -server it should work. If not we'll have to debug what went wrong there, breakage is bad :)
(In reply to comment #32) > (In reply to comment #30) > > Upgrading from 8.4.2 to 8.4.2-r1 requires a full dump/initdb/restore cycle if > > you use the default useflags! > > Ouch, that is unexpected. Yes and no;-) The bug was the old useflag defaulting to use float date time stamps. With -r1 integer date time are selected. This changes the physical layout of the database files, and a dump/restore is needed. > The setting should get pulled in to -server through pg_config set in -base, so > if you set it in -base and rebuild -base and -server it should work. > If not we'll have to debug what went wrong there, breakage is bad :) > Have tried this, and it works: postgres@seaborg:~ $ psql psql (8.4.2) Type "help" for help. postgres=# show integer_datetimes ; integer_datetimes ------------------- off (1 row) But this useflag is relevant for -server, not for -base. A client can connect to any cluster, intdatetimes or not, no recompilation or something is needed. But if you toggle pg_legacytimestamp an recompile the server(!) the database files are incompatible and the server will not start. I don't know if this flag even relevant to -base, except pg_config? The current situation is as minimun a little bit confusing :-)
I've coupled the useflags now so that -server forces the legacydatetime useflag on base too. I am unsure if this is the best solution, but at least it should avoid further confusion. Plus an elog message, so I think we have all bases covered :)
oh, how did this one manage to get marked as fixed? Oopsie. Reopen.
alpha/arm/ia64/s390/sh/sparc stable hopefully
ppc64 done; closing as last arch
