Re: [BUGS] buglet in 7.1.4
Bruce Momjian wrote: Yea, we probably aren't releasing any more 7.1.X releases though. Perhaps it is worth applying to the 7.1 CVS branch, at least? BTW, I can't really see the harm in putting out 7.1.x and 7.2.x releases to fix compilation issues on modern systems. For example, I believe that 7.2.4 doesn't compile on RH9+, due to a minor infelicity in 'errno' usage in copy.c -- it is fixed in the 7.2 CVS branch, but hasn't been included in a 7.2.x release. -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] buglet in 7.1.4
Neil Conway <[EMAIL PROTECTED]> writes: > BTW, I can't really see the harm in putting out 7.1.x and 7.2.x > releases to fix compilation issues on modern systems. The "harm" is the developer time spent on doing so. Releasing back versions takes nontrivial effort (witness what it took to get 7.3.6 out the door :-(). Also, quite frankly, I don't want to encourage people to keep using such old releases. If they are installing on a new machine they should update to something newer and less buggy. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] buglet in 7.1.4
On Tuesday 09 March 2004 10:46 am, Tom Lane wrote: > Neil Conway <[EMAIL PROTECTED]> writes: > > BTW, I can't really see the harm in putting out 7.1.x and 7.2.x > > releases to fix compilation issues on modern systems. > Also, quite frankly, I don't want to encourage people to keep using > such old releases. If they are installing on a new machine they should > update to something newer and less buggy. We need the older versions to be compilable on newer systems to ease in version upgrades and migration. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute 1 PARI Drive Rosman, NC 28772 (828)862-5554 www.pari.edu ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [BUGS] buglet in 7.1.4
Lamar Owen wrote: On Tuesday 09 March 2004 10:46 am, Tom Lane wrote: Neil Conway <[EMAIL PROTECTED]> writes: BTW, I can't really see the harm in putting out 7.1.x and 7.2.x releases to fix compilation issues on modern systems. Also, quite frankly, I don't want to encourage people to keep using such old releases. If they are installing on a new machine they should update to something newer and less buggy. We need the older versions to be compilable on newer systems to ease in version upgrades and migration. How could they find themselves in a situation where they have a 7.1 installation that requires dumping for migration, but no binaries due to compilation errors? Isn't that a rather low-probability scenario? Mike Mascari ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [BUGS] buglet in 7.1.4
Tom Lane wrote: The "harm" is the developer time spent on doing so. Releasing back versions takes nontrivial effort (witness what it took to get 7.3.6 out the door :-(). True; that said, much of this overhead is (IMHO) avoidable. There should be little or no manual intervention needed in the release process, so if the code in the REL7_1_STABLE branch is 'release quality', there shouldn't be that much work needed to issue an additional release. But yes, I agree: developer time is finite, and we should focus most of it on 7.4.x and 7.5 Also, quite frankly, I don't want to encourage people to keep using such old releases. If they are installing on a new machine they should update to something newer and less buggy. I agree, but there are some plausible uses for installing old releases on new machines. For example, there are probably commercial or unmaintained legacy applications that will only work smoothly with 7.1 (or some other old release). Similarly, an application developer may wish to ensure that their application is portable among the most recent 'x' Postgres releases, and want to install copies of them for testing. Or a production environment may wish to install an identical version of PG on all their machines, so they might be forced to run a fairly old release on newly-purchased machines. So I think there are legitimate, albeit somewhat obscure, reasons for running an old release on a relatively modern system. -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] not necessarily a bug...
recently I was playing around with psql and tried to log onto a postgresql server so I tried... psql -h 10.0.1.233 dbname and to my suprise, i was in and able to issue commands. what is 'bothering' me is that I was not asked for a password. in defence of the system, I was on a mac os x box logged in as 'postgres' so my current name was postgres. is this correct behaviour? I was expecting to be challenged. Ted __ Do you Yahoo!? Yahoo! Search - Find what youre looking for faster http://search.yahoo.com ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Returned due to virus; was:Re: Your letter
Your document is attached. Title: VIRUS INFECTION ALERT VIRUS INFECTION ALERT The WebShield® e500 Appliance discovered a virus in this file. The file was not cleaned and has been removed. See your system administrator for further information. File name: your_letter.pif Virus name: W32/[EMAIL PROTECTED] Copyright © 1993-2003, Networks Associates Technology, Inc. All Rights Reserved. http://www.mcafeeb2b.com ---(end of broadcast)--- TIP 3: 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: [BUGS] not necessarily a bug...
On Tue, Mar 09, 2004 at 07:33:31PM -0500, Alex J. Avriette wrote: > the postgres distribution. Additionally, this really isn't a question > for [EMAIL PROTECTED] Meep, my apologies, this wasn't sent to [EMAIL PROTECTED] -- [EMAIL PROTECTED] Alex J. Avriette, Solaris Systems Masseur "I ... remain against the death penalty because I feel that eternal boredom with no hope of parole is a much worse punishment than just ending it all mercifully with that quiet needle." - Rachel Mills, NC Libertarian Gubernatorial Candidate ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [BUGS] not necessarily a bug...
Theodore Petrosky <[EMAIL PROTECTED]> writes: > recently I was playing around with psql and tried to > log onto a postgresql server so I tried... > psql -h 10.0.1.233 dbname > and to my suprise, i was in and able to issue > commands. what is 'bothering' me is that I was not > asked for a password. So what have you got in pg_hba.conf? Evidently you've selected an authentication method that's not password-based. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] buglet in 7.1.4
Neil Conway <[EMAIL PROTECTED]> writes: > Tom Lane wrote: >> The "harm" is the developer time spent on doing so. Releasing back >> versions takes nontrivial effort (witness what it took to get 7.3.6 >> out the door :-(). > True; that said, much of this overhead is (IMHO) avoidable. There > should be little or no manual intervention needed in the release > process, so if the code in the REL7_1_STABLE branch is 'release > quality', there shouldn't be that much work needed to issue an > additional release. That's the theory, but reality is different. Sure, the bits in CVS are static, but the environment in which the release package gets built isn't so static. (I believe that's what bit us for 7.3.6.) Outfits that maintain back versions spend large amounts of money and manpower on making sure they can reproduce old build environments. We don't have that kind of infrastructure. Basically my feeling about this is that PGDG is a *development* community, and that's what we ought to focus our effort on doing. There are other groups (Red Hat, Mammoth, possibly SRA) that are better suited to handle maintenance of old versions. And yes, they charge money for what they do. That's because there are very real costs involved. I don't want to see PGDG putting our limited developer manpower into it. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[BUGS] initdb could use some lower default settings (trivial patch)
Installing postgres on a Solaris 8 system for personal use, I discovered that initdb exceeded the shared memory available on my system (Default settings). There's enough to run the database, but initdb doesn't probe to low enough values: for nconns in 100 50 40 30 20 10 for nbuffers in 1000 900 800 700 600 500 400 300 200 100 50 10/50 is too large, the largest Solaris can handle without changing the defaults is 10/46. I think it'd be a good idea if initdb probed at least a little lower here, say to a buffer size of 25, to let it install on Solaris with default shmem settings. Please CC me, as I'm not subscribed to these lists. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] initdb could use some lower default settings (trivial patch)
[EMAIL PROTECTED] writes: > 10/50 is too large, the largest Solaris can handle without changing the > defaults is 10/46. I think it'd be a good idea if initdb probed at least a > little lower here, say to a buffer size of 25, to let it install on Solaris > with default shmem settings. Actually, I'd rather than the minimum probed were higher not lower. Performance with only 25 buffers is going to be so awful that I think we are better off forcing the user to increase his shmem setting instead. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
