Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via or IRC
Bug 290535 - dev-db/postgresql-base-8.4* should have pg-intdatetime USE flag enabled by default
Summary: dev-db/postgresql-base-8.4* should have pg-intdatetime USE flag enabled by de...
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High minor (vote)
Assignee: PgSQL Bugs
Depends on:
Blocks: 285475
  Show dependency tree
Reported: 2009-10-26 07:06 UTC by redneb
Modified: 2010-01-26 20:37 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description redneb 2009-10-26 07:06:44 UTC
According to the release notes of postgres 8.4, 64-bit integer datetimes is now the default. The --disable-integer-datetimes option is provided for backwards compatibility.

Reproducible: Always
Comment 1 Johan Bergström 2009-10-28 15:48:57 UTC
Proposed patch below (and colored here: USE-flag naming is so-so, but still recognizable if you actually used the old one. Any suggestions?

diff -ur ./metadata.xml /usr/portage/dev-db/postgresql-base/metadata.xml
--- ./metadata.xml	2009-10-27 22:32:48.000000000 +0100
+++ /usr/portage/dev-db/postgresql-base/metadata.xml	2008-08-05 19:05:45.000000000 +0200
@@ -3,8 +3,7 @@
-  <flag name='pg-oldintdatetime'>Enable --disable-integer-datetimes configure
-  option, which changes PG to use 32-bit integers for timestamp storage 
-  (default for 8.3 and older)</flag>
+  <flag name='pg-intdatetime'>Enable --enable-integer-datetimes configure
+  option, which changes PG to use 64-bit integers for timestamp storage</flag>
diff -ur ./postgresql-base-8.4.1.ebuild /usr/portage/dev-db/postgresql-base/postgresql-base-8.4.1.ebuild
--- ./postgresql-base-8.4.1.ebuild	2009-10-28 16:41:12.000000000 +0100
+++ /usr/portage/dev-db/postgresql-base/postgresql-base-8.4.1.ebuild	2009-10-24 14:37:53.000000000 +0200
@@ -21,7 +21,7 @@
 	linguas_hr linguas_hu linguas_it linguas_ko linguas_nb linguas_pl
 	linguas_pt_BR linguas_ro linguas_ru linguas_sk linguas_sl linguas_sv
 	linguas_tr linguas_zh_CN linguas_zh_TW"
-IUSE="doc kerberos nls pam pg-oldintdatetime readline ssl threads zlib ldap ${IUSE_LINGUAS}"
+IUSE="doc kerberos nls pam pg-intdatetime readline ssl threads zlib ldap ${IUSE_LINGUAS}"
 wanted_languages() {
@@ -82,7 +82,7 @@
 		$(use_with kerberos gssapi) \
 		"$(use_enable nls nls "$(wanted_languages)")" \
 		$(use_with pam) \
-		$(use_enable !pg-oldintdatetime integer-datetimes ) \
+		$(use_enable pg-intdatetime integer-datetimes ) \
 		$(use_with ssl openssl) \
 		$(use_enable threads thread-safety) \
 		$(use_enable threads thread-safety-force) \
Comment 2 Johan Bergström 2009-10-28 15:54:17 UTC
...of course one can always make the "old" (pg-intdatetime) flag enabled by default. Not much of a difference except you'd probably want this on, always.
Comment 3 redneb 2009-10-28 22:08:35 UTC
I think the pg-oldintdatetime solution is the best. Note thought that with "--disable-integer-datetimes" you don't get 32-bit integers for timestamps, you get double precision floating-point ([1]).

Comment 4 redneb 2009-10-28 22:10:39 UTC
Actually pg-olddatetime would be even better.
Comment 5 Maciej Mrozowski gentoo-dev 2009-12-15 11:43:35 UTC
EAPI=1 provides IUSE defaults, what's wrong with just adding +pg_intdatetime in there? This will enable it by default with no user intervention and keep won't add inverse semantics.
What is 'pg-oldintdatetime' supposed to mean anyway?
Does --disable-integer-datetimes switch to floating point datetime storage? If so, pg-oldintdatetime should be called 'pg-floatdatetime' if any.
I'd vote for adding pg_intdatetime in IUSE defaults anyway.
Comment 6 redneb 2009-12-15 17:47:01 UTC
(In reply to comment #5)
> EAPI=1 provides IUSE defaults, what's wrong with just adding +pg_intdatetime in
> there? This will enable it by default with no user intervention and keep won't
> add inverse semantics.
> What is 'pg-oldintdatetime' supposed to mean anyway?
> Does --disable-integer-datetimes switch to floating point datetime storage? If
> so, pg-oldintdatetime should be called 'pg-floatdatetime' if any.
> I'd vote for adding pg_intdatetime in IUSE defaults anyway.

This is what I initially proposed. But the thing is, integer timestamps is now the default and --disable-integer-datetimes is a legacy option. So I think it makes more sense to have an option (initially disabled) that would enable the legacy behavior than having an option (initially enabled) to enable the default behavior. This way we encourage users to use interger timestamps whereas with +pg_intdatetime some users might start wondering what's this use flag that's being enabled by default. That's why I now propose a new use flag pg-legacytimestamps which is the negation of pg_intdatetime. I have already posted a patch (in bug 285475) that changes that.
Comment 7 Maciej Mrozowski gentoo-dev 2009-12-15 18:48:19 UTC
pg_legacytimestamp is fine (or pg_floattimestamp), but please no pg_oldintdatetimestamp

I would be a bit cautions with this, while in most cases indeed int64 is used, it's not a rule (it may be intended or actually a bug):

from interfaces/ecpg/pgtypeslib/dt.h for instance:
typedef int32 fsec_t;
typedef double fsec_t;

Which is not what everyone would expect.
Comment 8 Maciej Mrozowski gentoo-dev 2009-12-15 18:50:46 UTC
pg_legacydatetime that is - with USE flag description clearly stating that it falls back to float8/double time stamp storage.
Comment 9 Patrick Lauer gentoo-dev 2010-01-07 00:24:17 UTC
+  07 Jan 2010; Patrick Lauer <>                                                                                        
+  +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
Comment 10 Harald van Dijk (RETIRED) gentoo-dev 2010-01-08 05:41:27 UTC
Changing between pg-intdatetime and !pg-intdatetime means your server will no longer start, so the default should not have been changed in the ebuild without a big fat warning...
Comment 11 Maciej Mrozowski gentoo-dev 2010-01-08 12:16:15 UTC
Actually postgresql-server needs to be rebuilt *always* this change is done in postgresql-base (so that server libs and server executables have the same datetime format for database cluster).

Therefore I propose the following solution:

- move postgresql-server to EAPI-2 (to get USE deps)
- introduce pg_legacytimestamp USE flag in postgresql-server
- add USE dependency ~dev-db/postgresql-base-${PV}:${SLOT}[pg_legacytimestamp=]

I think it's worth reopening this bug (and I do it now) as simple upgrade even from 8.4.2 renders server in inconsistent state (and non working with existing database clusters).
Comment 12 Harald van Dijk (RETIRED) gentoo-dev 2010-01-08 18:37:59 UTC
You're probably right, but that's not what I meant. Install postgresql-{base,server} with the default USE="-pg-intdatetime", create a database, rebuild postgresql-{base,server} with the new default USE="-pg_legacytimestamp", try to start. Even though -base and -server are built to matching flags, this won't work.
Comment 13 Maciej Mrozowski gentoo-dev 2010-01-08 19:24:06 UTC
Note that I didn't say you're wrong :)
Of course at least pkg_postinst message is needed.
It's actually quite severe as databases need to be exported and recreated again from backup in order to migrate to integer timestamps - and it's not really straighforward procedure.

I even think it's worth adding in pkg_setup even with ebeep as one needs to export database before upgrading postgresql.

Good thing is actual issue is clearly stated in postgresql logs when one attempts to use server incompatible with database cluster so it's not like users (database administrators) are left helpless.
Comment 14 Gerhard Hintermayer 2010-01-19 19:32:58 UTC
(In reply to comment #13)
I was just running into this trap on a (thank good) non production server (except heating at home and collection some weather data :-) ). Postgresql's  thought behind minor release upgrades always was, that you just recompile the server and "A dump/restore is not required for those running 8.4.X" (from the Changelog)  What we have here now is, that a dump restore _IS_ required even for a minor update. Pls do not do that. Off course I can switch back to 8.4.2 in a glimpse. But I expect a minor update to work even on a production server with very short outage. I'd propose NOT breaking things when doing a minor update.
It's getting colder now, I better reemerge 8.4.2 now ;-) 

Comment 15 Patrick Lauer gentoo-dev 2010-01-26 20:37:09 UTC
I've added some elog notices and added the useflag to -server so it becomes really obvious. Hope that's enough to make you happy :)