Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Am Samstag, 24. November 2007 schrieb Bruce Momjian: Peter, were you going to address this? It's done now. diff -ur ../cvs-pgsql/configure.in ./configure.in --- ../cvs-pgsql/configure.in 2007-11-16 21:25:10.0 +0100 +++ ./configure.in 2007-11-16 22:27:36.0 +0100 @@ -19,7 +19,7 @@ AC_INIT([PostgreSQL], [8.3beta3], [EMAIL PROTECTED]) -AC_PREREQ(2.59) +m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.59], [], [m4_fatal([Autoconf version 2.59 is required])]) AC_COPYRIGHT([Copyright (c) 1996-2007, PostgreSQL Global Development Group]) AC_CONFIG_SRCDIR([src/backend/access/common/heaptuple.c]) AC_CONFIG_AUX_DIR(config) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Peter, were you going to address this? --- Peter Eisentraut wrote: Tom Lane wrote: Bruce's suggestion of somehow checking this in the top Makefile is a possibility, but even better would be if creating configure from configure.in failed outright. We have an AC_PREREQ in there that fails if autoconf is too old, but can we tighten it to also complain if too new? Yes: diff -ur ../cvs-pgsql/configure.in ./configure.in --- ../cvs-pgsql/configure.in 2007-11-16 21:25:10.0 +0100 +++ ./configure.in 2007-11-16 22:27:36.0 +0100 @@ -19,7 +19,7 @@ AC_INIT([PostgreSQL], [8.3beta3], [EMAIL PROTECTED]) -AC_PREREQ(2.59) +m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.59], [], [m4_fatal([Autoconf version 2.59 is required])]) AC_COPYRIGHT([Copyright (c) 1996-2007, PostgreSQL Global Development Group]) AC_CONFIG_SRCDIR([src/backend/access/common/heaptuple.c]) AC_CONFIG_AUX_DIR(config) This appears to work with 2.53, 2.59, and 2.61, which are the ones that affect us at the moment. I can backpatch this all the way to 7.3 if desired. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Gregory Stark wrote: Why is configure even checked in to CVS? Right now you don't even need autoconf installed to build out of CVS. Do we want to impose that as an extra requirement? And if we did it would need to be the same one used to cut tarballs, or one provably compatible. cheers andrew ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Tom Lane [EMAIL PROTECTED] writes: [EMAIL PROTECTED] (Marc G. Fournier) writes: configure (r1.570 - r1.571) (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.570r2=1.571) It appears that Marc has got autoconf 2.61 installed now, instead of the 2.59 that we've been using for some time. I'm a bit concerned about the implications of switching to a version that's got zero track record for us, and that AFAIK no other committers have installed. I'd rather see a switch happen at the start of a devel cycle than at beta3; and in any case it's got to be coordinated so that what is in the release doesn't vary depending on who committed last. Why is configure even checked in to CVS? That wouldn't change any of your questions though, it just shifts the point in the process at which the version of autoconf has to be controlled to the release tarball creation step rather than when people are checking in changes. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Magnus Hagander [EMAIL PROTECTED] writes: On Fri, Nov 16, 2007 at 09:04:38AM +0100, Peter Eisentraut wrote: Yeah, I think it's a bit insane. Keeping a few Autoconf versions around isn't hard at all. We have been doing it for years. (Hint: ./configure; make; make install) Yeah. I reiterate my point that I think it'd be good with a dedicated VM to build the snapshots and releases off, that isn't affected by other changes to whatever machine happens to be used. This VM could then be given all the required autoconf versions, and it'd stay stable - and wouldn't be affected by choices by whatever distribution is used. That would work for flex and bison but we're (inexplicably afaict) *checking in* the autoconf output into CVS. So it isn't the version of autoconf used to cut the release which matters, it's the last version anyone used to run autoconf. I guess part of Marc's release cutting routine is to rerun autoconf and check in that result? But that's arguably even worse. It means that after having tested the source with whatever version of autoconf the last configure.in hacker used for months we suddenly switch to whatever Marc's machine generates just before release. Of course having every developer run autoconf suffers from that problem too. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB's PostgreSQL training! ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
On Fri, Nov 16, 2007 at 10:32:13AM +0100, Peter Eisentraut wrote: Am Freitag, 16. November 2007 schrieb Magnus Hagander: Last time it was flex (or was it bison). This time autoconf (which I beleive has happened before as well). It *will* happen again. Just download autoconf, bison, flex from GNU and do a source install. That should cover the problem. Yes. It's easy to do. But unless we want to get bitten by this again, it has to live in a controlled environment. IMHO, of course ;-) //Magnus ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Am Freitag, 16. November 2007 schrieb Marc G. Fournier: I know right now we have three different versions 'required', just can't recall which fall under which ... You just look into the files to see what was used last time. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Am Freitag, 16. November 2007 schrieb Tom Lane: [ digs for a moment... ] According to my notes we are using autoconf 2.53 for versions 7.3-8.0 and 2.59 for the later branches. So 2.13 is already out of the picture. It might be that 2.53 to 2.59 to 2.61 is not all that big a jump in reality, but I've got to say that it scares me when I read commit-log entries that report ten thousand lines worth of diffs in a 20K-line script ... Yeah, I think it's a bit insane. Keeping a few Autoconf versions around isn't hard at all. We have been doing it for years. (Hint: ./configure; make; make install) -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Am Freitag, 16. November 2007 schrieb Magnus Hagander: Last time it was flex (or was it bison). This time autoconf (which I beleive has happened before as well). It *will* happen again. Just download autoconf, bison, flex from GNU and do a source install. That should cover the problem. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I reiterate my point that I think it'd be good with a dedicated VM to build the snapshots and releases off, that isn't affected by other changes to whatever machine happens to be used. This VM could then be given all the required autoconf versions, and it'd stay stable - and wouldn't be affected by choices by whatever distribution is used. That's really not the worst part of the problem. The worst part is that all developers who ever touch the configure script need to have the same autoconf version installed, and when dealing with back branches need to remember to use the right version. So I think focusing on only the environment used for tarball-building misses the point. We need a solution targeted at all-developers-including-Marc, not one that just sets the release process in stone. One idea people might suggest is to stop keeping the generated configure script in CVS. I'm not sure that'd make things better though. We'd be buying into the concept of trying to make configure.in work with any autoconf version any developer might be likely to use. I'm really not too sure what the functional incompatibilities between versions are, but given the extent of line-by-line diffs I've seen in the output of even adjacent versions, this isn't a question I want to take lightly. Could we compare the configure version used during the compile and throw an error to catch mismatches? You would have to hard-code the configure version into one of the static Makefiles. -- Bruce Momjian [EMAIL PROTECTED]http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 16, 2007 17:44:52 + Dave Page [EMAIL PROTECTED] wrote: Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 16, 2007 11:10:09 -0500 Tom Lane [EMAIL PROTECTED] wrote: I'm really not too sure what the functional incompatibilities between versions are, but given the extent of line-by-line diffs I've seen in the output of even adjacent versions, this isn't a question I want to take lightly. Just curious, but isn't that something the buildfarm would be good for? generate/commit a 6.1 version of configure, and see if any of hte buildfarm environments break ... or am I missing something 'post-install' that could be affected? Maybe the BF members could just run their default autoconf as part of the build if they have one. you lost me on that one ... Tom is hestitant about moving to 6.1 because we don't know what the fall out will be ... since I imagine the fallout would be in the configure/build stage, if we modified CVS to have a 6.1 configure script in place, wouldn't the buildfarm servers not be a good means to test *if* there is any fallout? - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPdjx4QvfyHIvDvMRAj6AAJwO7SFyhCi0qdFANX/5pWt8dagWFACff82K NbrLYsQF9JKIerV4DxPoljU= =gvyw -END PGP SIGNATURE- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier wrote: Maybe the BF members could just run their default autoconf as part of the build if they have one. you lost me on that one ... Tom is hestitant about moving to 6.1 because we don't know what the fall out will be ... since I imagine the fallout would be in the configure/build stage, if we modified CVS to have a 6.1 configure script in place, wouldn't the buildfarm servers not be a good means to test *if* there is any fallout? If the first thing some of them do is re-run autoconf, then we should get test results for a variety of versions as found on various distros. We would then be able to tell which versions may or may not work which could help us when we need to upgrade, or if someone has problems with a specific version when hacking (which should be rare I appreciate). /D ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Magnus Hagander wrote: Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I reiterate my point that I think it'd be good with a dedicated VM to build the snapshots and releases off, that isn't affected by other changes to whatever machine happens to be used. This VM could then be given all the required autoconf versions, and it'd stay stable - and wouldn't be affected by choices by whatever distribution is used. That's really not the worst part of the problem. The worst part is that all developers who ever touch the configure script need to have the same autoconf version installed, and when dealing with back branches need to remember to use the right version. So I think focusing on only the environment used for tarball-building misses the point. We need a solution targeted at all-developers-including-Marc, not one that just sets the release process in stone. So let's create a VM for just this? A VM is very cheap, it just costs a bit of disk space as long as it's not used. And give committers access to it, to use it for committing these changes (unless they are running the correct version at home - a simple cvs diff before committing should show you very clearly if you're not). And before it's suggested, this should not be the cvs VM. The cvs VM is a dedicated VM for just that for stability and security reasons. It should remain that. Even though it's a VM where all the devs have accounts already. I just don't see any great value in it. I keep trees for doing commit work on all branches on my workstation - I suspect most other committers do too. I'm going to want the relevant configure version where I do my work, so I can test things out. Having multiple versions around isn't a huge burden. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
On Fri, Nov 16, 2007 at 09:04:38AM +0100, Peter Eisentraut wrote: Am Freitag, 16. November 2007 schrieb Tom Lane: [ digs for a moment... ] According to my notes we are using autoconf 2.53 for versions 7.3-8.0 and 2.59 for the later branches. So 2.13 is already out of the picture. It might be that 2.53 to 2.59 to 2.61 is not all that big a jump in reality, but I've got to say that it scares me when I read commit-log entries that report ten thousand lines worth of diffs in a 20K-line script ... Yeah, I think it's a bit insane. Keeping a few Autoconf versions around isn't hard at all. We have been doing it for years. (Hint: ./configure; make; make install) Yeah. I reiterate my point that I think it'd be good with a dedicated VM to build the snapshots and releases off, that isn't affected by other changes to whatever machine happens to be used. This VM could then be given all the required autoconf versions, and it'd stay stable - and wouldn't be affected by choices by whatever distribution is used. Last time it was flex (or was it bison). This time autoconf (which I beleive has happened before as well). It *will* happen again. If we move to the latest autoconf now, it will just happen the next time distro of choice upgrades what they have. (I say distro of choice. In thi case it's freebsd, but I'm sure it happens on other platforms as well. For example, I notice my Gutsy box has a different autoconf from my Dapper one. Which is why I do my pg autoconf work on the dapper one) //Magnus ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
[EMAIL PROTECTED] (Marc G. Fournier) writes: configure (r1.570 - r1.571) (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.570r2=1.571) It appears that Marc has got autoconf 2.61 installed now, instead of the 2.59 that we've been using for some time. I'm a bit concerned about the implications of switching to a version that's got zero track record for us, and that AFAIK no other committers have installed. I'd rather see a switch happen at the start of a devel cycle than at beta3; and in any case it's got to be coordinated so that what is in the release doesn't vary depending on who committed last. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Thursday, November 15, 2007 20:49:04 -0800 Joshua D. Drake [EMAIL PROTECTED] wrote: Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 'k, 2.59 isn't even available in FreeBSD ports anymore, only 2.13 and 2.61, so can someone else please run autoconf and commit, and I'll re-tag ... I can't commit but I can give access to a 2.59 version... Well, easiest is for Tom to run autoconf 2.59 and commit ... or Bruce ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPSIc4QvfyHIvDvMRAoZCAJ9MF5wdAcB0aUTyT8qo62+DF61wywCfQLJF kSsl+ZTYu9SC+OEuA2NGPfU= =EDTa -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Magnus Hagander wrote: So let's create a VM for just this? This just moves the problem elsewhere: from use the right autoconf version to use the right VM. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier [EMAIL PROTECTED] writes: - --On Friday, November 16, 2007 00:40:31 -0500 Tom Lane [EMAIL PROTECTED] wrote: Perhaps so, but it'd cost us a fair amount of up-front work to verify that we don't break the back branches by updating their configure scripts. Not something I want to touch on a last-minute basis ;-) Wasn't suggesting 'last-minute', but maybe post 8.3 release, while things are a bit quiet? Sure, if someone wants to do the legwork early in 8.4 devel cycle, I'm all for it ... regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 16, 2007 11:10:09 -0500 Tom Lane [EMAIL PROTECTED] wrote: I'm really not too sure what the functional incompatibilities between versions are, but given the extent of line-by-line diffs I've seen in the output of even adjacent versions, this isn't a question I want to take lightly. Just curious, but isn't that something the buildfarm would be good for? generate/commit a 6.1 version of configure, and see if any of hte buildfarm environments break ... or am I missing something 'post-install' that could be affected? - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPdXm4QvfyHIvDvMRAsuEAJwJ4F5yISz8wa/AR9W/b2kwgEky/ACgh015 7KGhYRO3GoyT/M/2mJn9k24= =2/7/ -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Tom Lane wrote: Magnus Hagander [EMAIL PROTECTED] writes: I reiterate my point that I think it'd be good with a dedicated VM to build the snapshots and releases off, that isn't affected by other changes to whatever machine happens to be used. This VM could then be given all the required autoconf versions, and it'd stay stable - and wouldn't be affected by choices by whatever distribution is used. That's really not the worst part of the problem. The worst part is that all developers who ever touch the configure script need to have the same autoconf version installed, and when dealing with back branches need to remember to use the right version. So I think focusing on only the environment used for tarball-building misses the point. We need a solution targeted at all-developers-including-Marc, not one that just sets the release process in stone. So let's create a VM for just this? A VM is very cheap, it just costs a bit of disk space as long as it's not used. And give committers access to it, to use it for committing these changes (unless they are running the correct version at home - a simple cvs diff before committing should show you very clearly if you're not). And before it's suggested, this should not be the cvs VM. The cvs VM is a dedicated VM for just that for stability and security reasons. It should remain that. Even though it's a VM where all the devs have accounts already. One idea people might suggest is to stop keeping the generated configure script in CVS. I'm not sure that'd make things better though. We'd be buying into the concept of trying to make configure.in work with any autoconf version any developer might be likely to use. I'm really not too sure what the functional incompatibilities between versions are, but given the extent of line-by-line diffs I've seen in the output of even adjacent versions, this isn't a question I want to take lightly. Having it in cvs made life a *lot* easier when developing with mingw. Getting the proper autoconfy stuff going there is not easy at all. I'm sure there can be others having the same problems. I would much prefer a solution that keeps it in cvs. //Magnus ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 16, 2007 11:10:09 -0500 Tom Lane [EMAIL PROTECTED] wrote: I'm really not too sure what the functional incompatibilities between versions are, but given the extent of line-by-line diffs I've seen in the output of even adjacent versions, this isn't a question I want to take lightly. Just curious, but isn't that something the buildfarm would be good for? generate/commit a 6.1 version of configure, and see if any of hte buildfarm environments break ... or am I missing something 'post-install' that could be affected? Maybe the BF members could just run their default autoconf as part of the build if they have one. /D ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Dave Page wrote: Maybe the BF members could just run their default autoconf as part of the build if they have one. The problem here isn't really that we require a great testing and staging procedure for introducing new autoconf versions. The issue at hand is strictly that we shouldn't introduce a new autoconf version at the night of beta 3. When we want to move to a newer autoconf, we can handle it like any other patch. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 16, 2007 18:00:26 + Dave Page [EMAIL PROTECTED] wrote: Marc G. Fournier wrote: Maybe the BF members could just run their default autoconf as part of the build if they have one. you lost me on that one ... Tom is hestitant about moving to 6.1 because we don't know what the fall out will be ... since I imagine the fallout would be in the configure/build stage, if we modified CVS to have a 6.1 configure script in place, wouldn't the buildfarm servers not be a good means to test *if* there is any fallout? If the first thing some of them do is re-run autoconf, then we should get test results for a variety of versions as found on various distros. We would then be able to tell which versions may or may not work which could help us when we need to upgrade, or if someone has problems with a specific version when hacking (which should be rare I appreciate). Ah, okay, you are going for the 'remove pre-built configure from cvs' route .. that works too, and does make sense ... wouldn't definitely make sure we get broad coverage ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPdwq4QvfyHIvDvMRAiqvAKDdtV+AtsFZe9WkbG+7GYPRs+0zvQCeJGxX pY3WUGVHUgXtU1mfYIGAfBo= =wyE3 -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 That would be a good idea, and really simply things ... FreeBSD seems to have drop'd off support for all but 2.13 and 2.61 ... If we do that, (I honestly don't know) what happens on versions that are running an older version of autoconf? I mean, if everything is put together with 2.61, are 2.59 versions going to have an issue? Joshua D. Drake - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPShG4QvfyHIvDvMRAm48AJ9D7FOT0EyASLJuBmxeLbE+464HdgCg54fJ xQOk7rf3xBmwEreHKzlk3C4= =6M0k -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Andrew Dunstan [EMAIL PROTECTED] writes: We are making a mountain out of a molehill here. We've managed to get this right for years with very little fuss. Why make infrastructure to handle a problem that is at most marginal? I have more pressing concerns that building an autoconf step into buildfarm. I think that trying to get configure.in to work with arbitrary versions of autoconf is probably not a very useful expenditure of time, anyway. What we *do* need is some way of checking whether the right autoconf version was used in any particular branch; right now we simply rely on committers to get it right, and it's an easy thing to mess up. Bruce's suggestion of somehow checking this in the top Makefile is a possibility, but even better would be if creating configure from configure.in failed outright. We have an AC_PREREQ in there that fails if autoconf is too old, but can we tighten it to also complain if too new? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Andrew Dunstan wrote: (And I share Tom's concern about version compatibility - the autoconf team don't have a great record on that IIRC.) Thats why I think it might be useful to keep an eye on what does and doesn't work. I agree it's not a major issue though, so if it's non-trivial to implement then there's no point persuing the idea. /D ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 16, 2007 18:00:26 + Dave Page [EMAIL PROTECTED] wrote: Marc G. Fournier wrote: Maybe the BF members could just run their default autoconf as part of the build if they have one. you lost me on that one ... Tom is hestitant about moving to 6.1 because we don't know what the fall out will be ... since I imagine the fallout would be in the configure/build stage, if we modified CVS to have a 6.1 configure script in place, wouldn't the buildfarm servers not be a good means to test *if* there is any fallout? If the first thing some of them do is re-run autoconf, then we should get test results for a variety of versions as found on various distros. We would then be able to tell which versions may or may not work which could help us when we need to upgrade, or if someone has problems with a specific version when hacking (which should be rare I appreciate). Ah, okay, you are going for the 'remove pre-built configure from cvs' route .. that works too, and does make sense ... wouldn't definitely make sure we get broad coverage ... No, I wouldn't remove it - leave it there for some BF members, but have others regenerate it just for test purposes. /D ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: I can't commit but I can give access to a 2.59 version... Well, easiest is for Tom to run autoconf 2.59 and commit ... or Bruce ... Locally I've got several autoconf versions installed so that I can update back-branch configure scripts properly. It'd probably be a good idea to improve your release scripts so that they select the right autoconf version for each release branch. You'll need multiple local installations though, instead of depending on freebsd ports for the one true autoconf. Either that or we try to move up all supported back branches to the latest autoconf version; which might be a good idea but it scares me a bit. I say have a VMWare instance running with the one true autoconf that is currently accepted. That way we don't have to make that distinction. Autoconf 2.59 is going to be predominantly in the wild (rhel 5, centos5 , dapper, debian) for at least another 3-4 years. Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Tom Lane wrote: Bruce's suggestion of somehow checking this in the top Makefile is a possibility, but even better would be if creating configure from configure.in failed outright. We have an AC_PREREQ in there that fails if autoconf is too old, but can we tighten it to also complain if too new? Yes: diff -ur ../cvs-pgsql/configure.in ./configure.in --- ../cvs-pgsql/configure.in 2007-11-16 21:25:10.0 +0100 +++ ./configure.in 2007-11-16 22:27:36.0 +0100 @@ -19,7 +19,7 @@ AC_INIT([PostgreSQL], [8.3beta3], [EMAIL PROTECTED]) -AC_PREREQ(2.59) +m4_if(m4_defn([m4_PACKAGE_VERSION]), [2.59], [], [m4_fatal([Autoconf version 2.59 is required])]) AC_COPYRIGHT([Copyright (c) 1996-2007, PostgreSQL Global Development Group]) AC_CONFIG_SRCDIR([src/backend/access/common/heaptuple.c]) AC_CONFIG_AUX_DIR(config) This appears to work with 2.53, 2.59, and 2.61, which are the ones that affect us at the moment. I can backpatch this all the way to 7.3 if desired. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Dave Page wrote: Just curious, but isn't that something the buildfarm would be good for? generate/commit a 6.1 version of configure, and see if any of hte buildfarm environments break ... or am I missing something 'post-install' that could be affected? Maybe the BF members could just run their default autoconf as part of the build if they have one. We are making a mountain out of a molehill here. We've managed to get this right for years with very little fuss. Why make infrastructure to handle a problem that is at most marginal? I have more pressing concerns that building an autoconf step into buildfarm. (And I share Tom's concern about version compatibility - the autoconf team don't have a great record on that IIRC.) cheers andrew ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Peter Eisentraut [EMAIL PROTECTED] writes: Tom Lane wrote: Bruce's suggestion of somehow checking this in the top Makefile is a possibility, but even better would be if creating configure from configure.in failed outright. We have an AC_PREREQ in there that fails if autoconf is too old, but can we tighten it to also complain if too new? Yes: Excellent. This appears to work with 2.53, 2.59, and 2.61, which are the ones that affect us at the moment. I can backpatch this all the way to 7.3 if desired. Please. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Magnus Hagander [EMAIL PROTECTED] writes: I reiterate my point that I think it'd be good with a dedicated VM to build the snapshots and releases off, that isn't affected by other changes to whatever machine happens to be used. This VM could then be given all the required autoconf versions, and it'd stay stable - and wouldn't be affected by choices by whatever distribution is used. That's really not the worst part of the problem. The worst part is that all developers who ever touch the configure script need to have the same autoconf version installed, and when dealing with back branches need to remember to use the right version. So I think focusing on only the environment used for tarball-building misses the point. We need a solution targeted at all-developers-including-Marc, not one that just sets the release process in stone. One idea people might suggest is to stop keeping the generated configure script in CVS. I'm not sure that'd make things better though. We'd be buying into the concept of trying to make configure.in work with any autoconf version any developer might be likely to use. I'm really not too sure what the functional incompatibilities between versions are, but given the extent of line-by-line diffs I've seen in the output of even adjacent versions, this isn't a question I want to take lightly. regards, tom lane ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 'k, 2.59 isn't even available in FreeBSD ports anymore, only 2.13 and 2.61, so can someone else please run autoconf and commit, and I'll re-tag ... - --On Thursday, November 15, 2007 23:37:22 -0500 Tom Lane [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Marc G. Fournier) writes: configure (r1.570 - r1.571) (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.570 r2=1.571) It appears that Marc has got autoconf 2.61 installed now, instead of the 2.59 that we've been using for some time. I'm a bit concerned about the implications of switching to a version that's got zero track record for us, and that AFAIK no other committers have installed. I'd rather see a switch happen at the start of a devel cycle than at beta3; and in any case it's got to be coordinated so that what is in the release doesn't vary depending on who committed last. regards, tom lane - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPSCd4QvfyHIvDvMRApMlAJsFhy+DGsSXMzy6bH0FAEQl11zBKwCfbIQ6 66Upa6SjHDUccKm+Mun/l+g= =rNQj -END PGP SIGNATURE- ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Tom Lane wrote: [EMAIL PROTECTED] (Marc G. Fournier) writes: configure (r1.570 - r1.571) (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.570r2=1.571) It appears that Marc has got autoconf 2.61 installed now, instead of the 2.59 that we've been using for some time. I'm a bit concerned about the implications of switching to a version that's got zero track record for us, and that AFAIK no other committers have installed. I'd rather see a switch happen at the start of a devel cycle than at beta3; and in any case it's got to be coordinated so that what is in the release doesn't vary depending on who committed last. O.k., so what do you want to do? Or more to the point, is there something I can help with? I have machines with 2.59... Marc do you have any left with 2.59? Sincerely, Joshua D. Drake regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 'k, 2.59 isn't even available in FreeBSD ports anymore, only 2.13 and 2.61, so can someone else please run autoconf and commit, and I'll re-tag ... I can't commit but I can give access to a 2.59 version... Sincerely, Joshua D. Drake - --On Thursday, November 15, 2007 23:37:22 -0500 Tom Lane [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] (Marc G. Fournier) writes: configure (r1.570 - r1.571) (http://developer.postgresql.org/cvsweb.cgi/pgsql/configure?r1=1.570 r2=1.571) It appears that Marc has got autoconf 2.61 installed now, instead of the 2.59 that we've been using for some time. I'm a bit concerned about the implications of switching to a version that's got zero track record for us, and that AFAIK no other committers have installed. I'd rather see a switch happen at the start of a devel cycle than at beta3; and in any case it's got to be coordinated so that what is in the release doesn't vary depending on who committed last. regards, tom lane - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPSCd4QvfyHIvDvMRApMlAJsFhy+DGsSXMzy6bH0FAEQl11zBKwCfbIQ6 66Upa6SjHDUccKm+Mun/l+g= =rNQj -END PGP SIGNATURE- ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Thursday, November 15, 2007 20:49:04 -0800 Joshua D. Drake [EMAIL PROTECTED] wrote: Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 'k, 2.59 isn't even available in FreeBSD ports anymore, only 2.13 and 2.61, so can someone else please run autoconf and commit, and I'll re-tag ... I can't commit but I can give access to a 2.59 version... Well, easiest is for Tom to run autoconf 2.59 and commit ... or Bruce ... *shrug* :) helping where I can... number is on pmt if you need me :) Joshua D. Drake - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPSIc4QvfyHIvDvMRAoZCAJ9MF5wdAcB0aUTyT8qo62+DF61wywCfQLJF kSsl+ZTYu9SC+OEuA2NGPfU= =EDTa -END PGP SIGNATURE- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: I can't commit but I can give access to a 2.59 version... Well, easiest is for Tom to run autoconf 2.59 and commit ... or Bruce ... Locally I've got several autoconf versions installed so that I can update back-branch configure scripts properly. It'd probably be a good idea to improve your release scripts so that they select the right autoconf version for each release branch. You'll need multiple local installations though, instead of depending on freebsd ports for the one true autoconf. Either that or we try to move up all supported back branches to the latest autoconf version; which might be a good idea but it scares me a bit. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Thursday, November 15, 2007 21:21:59 -0800 Joshua D. Drake [EMAIL PROTECTED] wrote: Marc G. Fournier wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 That would be a good idea, and really simply things ... FreeBSD seems to have drop'd off support for all but 2.13 and 2.61 ... If we do that, (I honestly don't know) what happens on versions that are running an older version of autoconf? I mean, if everything is put together with 2.61, are 2.59 versions going to have an issue? I believe Tom was suggesting upgrading and testing them to make sure of that ... instead of having 7.3 using one version, 7.4 and 8.0 usnig another, and 8.1 and beyond using a third ... I know right now we have three different versions 'required', just can't recall which fall under which ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPSnf4QvfyHIvDvMRAjZSAJ9D28LaQ3abmr6Mb4/vWpwACR602ACgvBP9 18xCapgj6muv2SuYNrLzv+8= =HvQG -END PGP SIGNATURE- ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 16, 2007 00:03:46 -0500 Tom Lane [EMAIL PROTECTED] wrote: Marc G. Fournier [EMAIL PROTECTED] writes: [EMAIL PROTECTED] wrote: I can't commit but I can give access to a 2.59 version... Well, easiest is for Tom to run autoconf 2.59 and commit ... or Bruce ... Locally I've got several autoconf versions installed so that I can update back-branch configure scripts properly. It'd probably be a good idea to improve your release scripts so that they select the right autoconf version for each release branch. You'll need multiple local installations though, instead of depending on freebsd ports for the one true autoconf. Either that or we try to move up all supported back branches to the latest autoconf version; which might be a good idea but it scares me a bit. That would be a good idea, and really simply things ... FreeBSD seems to have drop'd off support for all but 2.13 and 2.61 ... - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPShG4QvfyHIvDvMRAm48AJ9D7FOT0EyASLJuBmxeLbE+464HdgCg54fJ xQOk7rf3xBmwEreHKzlk3C4= =6M0k -END PGP SIGNATURE- ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier [EMAIL PROTECTED] writes: - --On Friday, November 16, 2007 00:03:46 -0500 Tom Lane [EMAIL PROTECTED] wrote: Either that or we try to move up all supported back branches to the latest autoconf version; which might be a good idea but it scares me a bit. That would be a good idea, and really simply things ... FreeBSD seems to have drop'd off support for all but 2.13 and 2.61 ... Perhaps so, but it'd cost us a fair amount of up-front work to verify that we don't break the back branches by updating their configure scripts. Not something I want to touch on a last-minute basis ;-) [ digs for a moment... ] According to my notes we are using autoconf 2.53 for versions 7.3-8.0 and 2.59 for the later branches. So 2.13 is already out of the picture. It might be that 2.53 to 2.59 to 2.61 is not all that big a jump in reality, but I've got to say that it scares me when I read commit-log entries that report ten thousand lines worth of diffs in a 20K-line script ... regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - --On Friday, November 16, 2007 00:40:31 -0500 Tom Lane [EMAIL PROTECTED] wrote: Marc G. Fournier [EMAIL PROTECTED] writes: - --On Friday, November 16, 2007 00:03:46 -0500 Tom Lane [EMAIL PROTECTED] wrote: Either that or we try to move up all supported back branches to the latest autoconf version; which might be a good idea but it scares me a bit. That would be a good idea, and really simply things ... FreeBSD seems to have drop'd off support for all but 2.13 and 2.61 ... Perhaps so, but it'd cost us a fair amount of up-front work to verify that we don't break the back branches by updating their configure scripts. Not something I want to touch on a last-minute basis ;-) Wasn't suggesting 'last-minute', but maybe post 8.3 release, while things are a bit quiet? - Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) iD8DBQFHPS7E4QvfyHIvDvMRAvgVAKDZ4OlC6dcwIeTu4APXYTfQ6XArlwCdEtBz ApsX48H6dalG+KJDVy0m+rA= =RFnE -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: update files for beta3
Marc G. Fournier [EMAIL PROTECTED] writes: 'k, 2.59 isn't even available in FreeBSD ports anymore, only 2.13 and 2.61, so can someone else please run autoconf and commit, and I'll re-tag ... Done regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
