Re: [Pgsqlrpms-hackers] [HACKERS] Safer auto-initdb for RPM init
On Saturday 26 August 2006 22:08, Matthew T. O'Connor wrote: > Joshua D. Drake wrote: > > Matthew T. O'Connor wrote: > >> script. If we installed the datadir during the RPM install, it would > >> still be newbie friendly and would removed initdb from start script > >> solving that problem. > > initdb will not overwrite an existing installation. > Poorly chosen words. I meant, the problem where the start script will > create a new data dir when it doesn't see that one exists even though > one actually does exist it's just not available at the moment. Either > way, if the start scripts never created a data dir, then there is no > problem. If a prebuilt datadir tree were available, it would make it even easier for people to overwrite their existing data, as RPM does not check non-RPM-managed files prior to overwriting them. This was in fact done several years ago by Red Hat, and was speedily removed. I understand the needs from both angles; so I'll ask just a simple question: which is worse, annoying all the newbies who just want to get started quickly, or annoying the small number of people who NFS mount their datadirs? (I personally wouldn't in a million years trust NFS for ACID compliance; maybe iSCSI, but NFS?!?!). The behavior, in my opinion, should be configurable and ON by default. -- 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] large object regression tests
On Tuesday 05 September 2006 02:59, Jeremy Drake wrote: > I am considering, and I think that in order to get a real test of the > large objects, I would need to load data into a large object which would > be sufficient to be loaded into more than one block (large object blocks > were 1 or 2K IIRC) so that the block boundary case could be tested. Is > there any precedent on where to grab such a large chunk of data from? I > was thinking about using an excerpt from a public domain text such as Moby > Dick, but on second thought binary data may be better to test things with. A 5 or 6 megapixel JPEG image. Maybe a photograph of an elephant. -- 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 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
The long-lost pg_upgrade (was:Re: [HACKERS] 8.2 features status)
On Friday 04 August 2006 02:20, Josh Berkus wrote: > Aren't I, the marketing geek, supposed to be the one whining about > this? [snip] > > * In-place upgrades (pg_upgrade) > BTW, I may get Sun to contribute an engineer for this; will get you posted. Long time no post. This statement really caught my attention; bravo if true upgrading can happen, and someone can be put on it and do it right. As Tom said, a little farther down the thread, we have talked over this many times. I specifically remember, oh, about a dozen times I personally have 'gadflied' this issue. As one who now has a, let's see: [EMAIL PROTECTED] ~]# du /var/lib/pgsql/data -s 16668528/var/lib/pgsql/data [EMAIL PROTECTED] ~]# Yes, a 16GB inventory database, with in-database large object images. Anyway, as one who does not look forward to migrating this the old-fashioned way (I can just imagine how fas^H^H^Hslow a restore of all those large objects is going to be; backup is slow enough (about 50 minutes on this Xeon 2.4GHz box)), in place upgrade would cut this considerably; the database is not a complex one, just a largish one. It's, let's see, only holding a little less than 5,000 items with associated lo images (due to many factors, this is handled through ODBC from Microsoft Access; it is a kludge, and a big one, but it works very smoothly from the users' points of view, where item images are literally 'dragged and dropped' from the digital camera straight to the database). So, anyway, looking forward to seeing some progress in this department... :-) -- 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 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] pg_config, pg_service.conf, postgresql.conf ....
On Monday 27 February 2006 21:09, Bruce Momjian wrote: > One question I have is how this feature would be an improvement over > just pointing pg_ctl at a postgresql.conf configuration file. That > config file has the ability to specify most if not all server > parameters. The big problem is that postgresql.conf is dynamically generated during initdb, and its location depends upon initdb's parameters directly. This makes it difficult to distribute, at least for packagers, a template of postgresql.conf or a 'default' postgresql.conf that plays nice with multiple versions and clusters, yet has centralized database tracking. -- 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 6: explain analyze is your friend
Re: [HACKERS] pg_config, pg_service.conf, postgresql.conf ....
On Monday 27 February 2006 19:59, Josh Berkus wrote: > > My frustration level often kills any desire to contribute to open > > source. Sometimes, I think that open source is doomed. The various > > projects I track and use are very frustrating, they remind me of > > dysfunctional engineering departments in huge companies, it is very hard > > to positively discuss any new ideas. The first response is always some > > variation on "no." > Well, if you weren't a regular I'd be more encouraging. But you already > know how things work here, so we can give you a hard time.I'll point > out the year-long argument over the newsysviews for the contributors, the > two-year long process for 2PC, etc. For what it's worth, I've been longing for a multiple cluster multi-version capable centralized startup and control mechanism for at least five years, and I think the archives would bear this out. I just have never had the time to implement it, and it was always an RPM-centric thought plan for me. -- 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 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] Updated email signature
On Saturday 18 February 2006 12:16, Michael Fuhr wrote: > On Sat, Feb 18, 2006 at 09:28:58AM -0500, Lamar Owen wrote: > > In 1982 I was doing hexadecimal machine code on that TRS-80 Model III, > > whose non-disk boot lines you quote. My favorite Z80 joke: > > 01 > > 110100 > > 21 > > EDB0 > > (Punchline: one-track mind.) > > Heh heh :-) Did plenty of that, though usually on 3C00-3FFF. Most efficient way to bitblit on the TRS-80although using the six pixel character cell graphics was, to say the least, _interesting_. I did a LIFE on the TRS-80 complete with a full screen graphical editor in 512 bytes. No assembly required; I may have the DEBUG listing around somewhere...time to pull out the catweasel. Ok, too off-topic. Sorrylast on-list post from me on that branch of the thread... -- 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Updated email signature
On Friday 17 February 2006 20:44, Michael Fuhr wrote: > On Fri, Feb 17, 2006 at 09:35:32PM -0400, Marc G. Fournier wrote: > > Sorry, I was still in Junior High in '82 :( Man, you are *old* :) > > Anybody know some reasonable postgresql.conf settings for a system > that starts up with > > Cass? > Memory Size? > > 'cuz I still have one :-) And running xtrs, anyone can have one. I go (TRS-80-wise) a little earlier than that, as my first documented Usenet post asserts: http://groups.google.com/group/alt.folklore.computers/browse_thread/thread/aedd5baeb2e4e6ba/af8a503f1a33a192?lnk=st&q=%22lamar+owen%22&rnum=16&hl=en#af8a503f1a33a192 Prior to that I did some FIDO with a TRS-80 odel 16B under Xenix System III. In 1982 I was doing hexadecimal machine code on that TRS-80 Model III, whose non-disk boot lines you quote. My favorite Z80 joke: 01 110100 21 EDB0 (Punchline: one-track mind.) PostgreSQL in 48K? Ouch. What's wild is that the level-1 cache on my current processor is larger than that... So, as to Usenet, earliest documented date is May 1992. Ran a leaf node with Waffle for a while, then an AT&T 3B1 later, running C News and SMail. So, Tom, did you enjoy being linked with the Backbone Cabal? What part did you play in the Great Renaming? Man, this is totally off-topic, but a fun distraction... -- 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 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] [pgsql-www] About my new work at Command Prompt Inc.
Devrim Gunduz Wrote: > Command Prompt Inc.has just hired me for my community work I have been > doing so far, like PostgreSQL RPM stuff and other PostgreSQL related > RPMs, such as Slony-I, pgpool, PostGIS, etc) and website things. That > means I'll spend more time on these. Congratulations, Devrim. You're doing a fine job on all those fronts; I believe the decision we made last year to pass the RPM maintenance to you was a wise one indeed, as you have stepped up to the plate nicely, and have furthered the RPM's considerably from where my efforts had taken them; I just wanted to mention that publicly to all those on these lists. -- 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 2: Don't 'kill -9' the postmaster
Re: [HACKERS] 8.1 Release Candidate 1 Bundled ...
>> The developer.postgresql.org machine really isn't geared to handle >> downloads.. Any reason you can't just stick it on the standard ftp sites >> and have it mirrored along with everything else? > This is taken from our spec: > # Pre-release RPM's should not be put up on the public ftp.postgresql.org > server > # -- only test releases or full releases should be. > So thinking that: > * Beta and RC RPMs are used only by testers > * We use the beta and RC steps to build the new RPM sets, so that means > that actually they are not production quality looking from the RPM > perspective. By way of clarification, as I am the one who wrote that portion of the spec file, an 'RPM prerelease' and a 'beta' weren't intended to be the same thing; the line in the spec referenced was for my own use to remind me that my own internal testing packages (with a release number 0.x) weren't intended for public consumption. Devrim, you can remove that section of the spec file at any time at this point, because you are using CVS for the purpose that I was using 'prerelease' RPMs. Historically, beta and release candidate RPM's were put on the main ftp site but flagged as beta quality. I certainly appreciate your dilligence in following those instructions I wrote long ago, but, thanks to your smoother release process (in no small part due to the use of CVS) those instructions are obsolete. Many thanks for being that dilligent! -- 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 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 8.02 rpm error
On Friday 20 May 2005 09:43, Dave Cramer wrote: > Lamar Owen wrote: > >On Friday 20 May 2005 07:55, Dave Cramer wrote: > >>Well, there's not much discussion here. Other than the fact that a few > >>things depend on libpq.so.3. > >>Isn't the standard to keep libpq.so.(n-1) whenever you bump the number up > >> ? > >Only because libpq versioning has always been an afterthought in the > > upstream release process. > OK, so how do we fix this ? Any time a change is made to libpq that changes its exported symbols or ABI a version change needs to be made. The person committing the change that impacts the ABI needs to be the person responsible for changing the version number; otherwise someone needs to monitor libpq changes coming down committers and remind people when they need to bump the libpq major or minor so version. Further, any time a release is being built one of the top things on the checklist should be 'is libpq's soname appropriate or not?' Changing past releases is impossible and must be worked around, which is quite honestly ugly to do. The cleanest thing, yet painful as it is, is to simply not provide the .3 at all and people will just have to rebuild all their clients. This gives a clean break; no, we can't fix 8.0.0, but we can fix from this point forward. People will complain, loudly, when it's broken; but which is better? Forcing a clean break with one-time pain, or having pain every single 8.0.x release? This situation should really drive home the importance of being careful! Basically it boils down to being more careful when piping out a release. PostgreSQL is no longer an island where we depend on OS services and few people depend on us; rather, libpq in particular is becoming a core component of distributions all around, and thus libpq must be very carefully maintained as a result; we have to, pardon the pun, watch our p-q's. Too many other projects are depending upon the soname in libpq to indicate the exported interface. And, where exported interfaces vary according to compile-time options, we need to change the soname based on the options (such as SSL versus non-SSL builds). And we must be consistent in the versioning; people tend to expect minor version upgrades to not break things, and 8.0.1 broke things. The discussion on why the version was bumped this time is in the archives; people are now fighting a battle with that decision. The decision to bump the version of libpq was the correct one to make; it just should have been made before 8.0 was released and not after. But all this discussion is in the archives; I would suggest browsing those threads. The fftw3 library provides a reasonable model with which to work; there are multiple compile-time options there that dramatically change the ABI (things like integer versus single-precision float versus double-precision float), and the route the fftw3 developers have taken is to make separate names for each. This way OS linking and dependency resolution isn't broken arbitrarily because otherwise there is no way of communicating to the linkloader which ABI we're exporting today. And I've made enough release piping errors to recognize one :-) -- 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: [HACKERS] 8.02 rpm error
On Friday 20 May 2005 07:55, Dave Cramer wrote: > Well, there's not much discussion here. Other than the fact that a few > things depend on libpq.so.3. > Isn't the standard to keep libpq.so.(n-1) whenever you bump the number up ? Only because libpq versioning has always been an afterthought in the upstream release process. The RPMset has worked around this in the past by providing fake previous versions; but it is just an ugly workaround of broken upstream behavior. This is not a new issue, unfortunately. That is, symlinks were provided to the new version of the library that masqueraded as previous versions, but weren't really previous versions. That can cause it's own broken behavior. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: Learning curves and such (was Re: [HACKERS] pgFoundry)
On Tuesday 17 May 2005 01:41, Josh Berkus wrote: > > > To put it much more bluntly: PostgreSQL development (both the process > > > and the codebase) has one of the steepest learning curves around, > You haven't looked at the OpenOffice.org code. Yes, I have. Yes, it's steeper. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgFoundry
On Monday 16 May 2005 14:07, Tom Lane wrote: > Andrew Dunstan <[EMAIL PROTECTED]> writes: > > This could in a sense be as simple as > > prioritising the TODO list. > But the TODO list could certainly be made more informative without > getting into that swamp. We need to prune the TODO list to make it more useful. This will be hard, this is true, but if a pruning discussion for each item on the list is held then the real interest in the item would stick out like a sore thumb. It's just too big and not really hierarchical. Are we too close to freeze and beta on 8.1 to have this sort of discussion? It doesn't need to be discussed close to a beta cycle, IMO, or it could easily turn into the huge distraction Tom speaks of. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pgFoundry
On Monday 16 May 2005 14:12, Robert Treat wrote: > On Mon, 2005-05-16 at 12:50, Lamar Owen wrote: > > The only way in my mind to get this dynamism on the website is to make > > the website part of the process at some level. If someone has to go > One idea I've tossed around is requiring patches to include release > notes, and then display the release notes on the web site as a "done so > far" type of list. It doesn't get you what is under active development, > but would get you a more up-to-date picture of changes as a release > evolves. Well, there is always the '-committers' list; if all CVS commits had/have meaningful commit changelog notices, then that could drive something. There are two things being talked about here: 1.) A forward-looking rad map; 2.) A status indication of where development is happening, and a history of past development. In my mind 2 is more important than 1, for all the reasons Tom already mentioned. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] pgFoundry
On Saturday 07 May 2005 16:23, Joshua D. Drake wrote: > > What does it mean to "track" the status of something? How would the > > status change except by discussion? What would be the point of announcing > > the status of something without allowing people to comment? > No one said anything about not letting people comment or discuss. What I > am suggesting is a better public presentation of what the heck is going > on with PostgreSQL development. This has been a perennial problem and has existed at least since version 6.1.0, as that's when I first noticed it. Looking at the website alone doesn't show the dynamic development that is actually happening, and has never shown it. I very nearly passed PostgreSQL by because it looked unmaintained at the time from looking at the website. That cannot be said at this juncture, but at the same time that is not real indication of how dynamic things really are. >From a sidelines point of view, a developer status summary page would allow one to follow development without having to read every message in HACKERS. At this point in my work, I am unable to follow development like I once did (one reason I stepped down as RPM maintainer) and have no real idea of the direction for 8.1 as a result. To put it much more bluntly: PostgreSQL development (both the process and the codebase) has one of the steepest learning curves around, steeper even than Plone, which is acknowledged by many to have an incredibly steep learning curve. The only way in my mind to get this dynamism on the website is to make the website part of the process at some level. If someone has to go through and digest for the website (hacker-bits, a la general bits) then that takes away developer resources (because someone has to be fairly close to the development process to do that sort of digestion). Rather, if developers are using a system that automatically pushes to a web interface (or even uses a web interface with a cli component) then the status is automatically generated and the work of updating status is distributed. > > I think you have a severely flawed idea of how free software development > > proceeds. > Then you obviously aren't paying attention. Look at other major OSS > projects. They have these things in place. Even the Linux kernel has a > bugzilla (although I am not advocating bugzilla). Not to mention KDE, > Gnome, Debian.. > These projects also have reasonably defined milestones for particular > releases and show status of those milestones during the release. Virtually all OSS projects I am involved with publish a generalized road map online. Some are more organized than others. PostgreSQL has a different culture, this is true. But it is somewhat of an intimidating culture for an outsider; once 'inside' (which takes 6 months or more unless you're another Tom Lane (I love going back and reading the way he just 'jumped in' to the project)) this is one of the friendliest development communities around. One might say the high bar of entry and the steep learning curve is partly the reason for that; culture changes take careful thought to implement, and a web-published development might easily change the whole culture of the project. The biggest flamewars I have seen here involve one of the following topics: 1.) GPL vs BSD 2.) MySQL 3.) Multithreaded versus multiprocess. Most other communities (with the notable exception of the GNUradio community, which is even more polite than this one, something I thought was not possible) have many more hot button topics than three. Like any other management process (sorry, those of you who think OSS means 'no management' - there is management here) the PostgreSQL process is unique due to the unique collection of members, and what works for one community won't necessarily work for another. Having said that, I'd love an 'at-a-glance' development status showing, possibly in graphical terms, where each subproject of the PostgreSQL core is at right now, updated frequently, as I've changed into more of a user role than a developer role; I can see the forest now, instead of all the RPM bushes and prairie grass. -- 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 8: explain analyze is your friend
[HACKERS] RPMS, time, and other things.
It is with some sadness I write this message to this group of talented people that I have come to think of as almost an extended family. As release time for PostgreSQL 8.0 comes near, I find myself unable to spend as much time on RPMs as I once did; frankly, I find myself not quite as interested in doing so as I once did. The situation in which I jumped feet first back in July of 1999 was one where RPMs for Red Hat releases came out infrequently, and where upgrading RPMs was fraught with peril. Times have changed: Red Hat now employs Tom Lane full-time to work on PostgreSQL; Red Hat RPM releases, handled by Tom, are both frequent and well-managed; another community maintainer, Devrim Gunduz, has stepped up to the plate and has managed the release of several RPMs at this point. These are good changes. Upgrading RPMs of PostgreSQL is still fraught with peril, however. I had attempted to make this easier at one point, but it turned into a maintenance nightmare, causing me to remove the half-attempt. I had a plan to help in this by allowing multiple versions of PostgreSQL to coexist (which I would still like to see happen, although I cannot at this time take the time to do it myself), but found myself unable to complete the probably small amount of work necessary to make it happen. This project deserves some fresh interest in this area; thus, I am stepping down as active RPM maintainer. I do not intend to unsubscribe from this list, however, and I intend to make myself available to answer Devrim and Tom (or anyone else!) on any questions they may have regarding the RPM packaging. I may critique from time-to-time the packaging, if Devrim doesn't mind, but I just simply cannot invest as much of my dwindling free time any more. My apologies for not making this decision earlier in the 8.0 beta cycle. This is a great group; in my opinion it is THE best open source development communities in existence anywhere. I have been honored to have served in this capacity, and look forward to PostgreSQL's continuing improvement due to the marvelous efforts of this active, vibrant, community. -- 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: [HACKERS] Time off
[late on a Saturday night, getting ready to go to bed, after putting four to bed: this topic is just too good to pass onapologies in advance...] On Saturday 23 October 2004 17:16, Steve Crawford wrote: > > Its also an unusual replication scheme in that, more often than > > not, the slaves control the masters. > As the slave of a replica with an 86 day 16 hour uptime I've also > discovered that the new I/O functions take some adjustment as does > working around the lack of sleep(3). The 9 month bootstrap time does cause some interesting latency issues, not to mention the nondeterministic behavior and unpredictable endianess of the processors that can cause the controlling init to fallback to heuristic techniques of initing processes in parallel, out-of-order, speculative, deeply and randomly pipelined manners. INTERCAL is easier to program than the machine code of these replicas. Forget the trampolines of COME-FROM. You get the wonders of ME-TOO and HE-DID_IT. Endless loops of DID-TO::DID_NOT require the deepest programming discipline, and sometimes a nonmaskable interrupt, to break. But the WHY loop is the most difficult, since the degree of precision of the controlling conditional constantly and randomly changes. But very few programming tasks are more rewarding than bringing this NDIA of the last order to code maturity, and even to version 2.0. Process migration issues abound, but are necessary for proper process stability. The controlling init process pair often has difficulty free'ing malloc'ed resources while migrating child processes. Inevitable memory leaks occur, with free'ed resources never equalling malloc'ed ones. But when the replica forks, and spawns its own child process, resource utilization goes up; but fortunately the VM code can easily swap back to the home of the originating processes. Here with four, one big endian with an 10y26w5d5h41m uptime, one little endian with 9y27w6d21h37m, one little endian at 7y7w2d22h14m, and one little endian 2y2w1d4h56m (due to kernel/init spawn events, uptime resolutions of less than a minute are difficult, if not impossible, to determine due to time dilation effects at kernel-initprocess handoff, where the spawning init loses timeslices during replica kernel respawn.). Endian conflicts abound, but uptime-related conflicts abound more, with significant replica competition for init process timeslices; all such attempts typically require superuser intervention to re-nice. *ducking*and*grinning* -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL Core Committee Welcomes New Member
On Wednesday 15 September 2004 18:52, Marc G. Fournier wrote: > In recognition of his role as lead developer on the internationalization > front, as well as his invaluble work in both the build and release > processes, Peter Eisentraut has been invited, and has accepted, to join > the Core Committee. If I may say so, 'It's about time!' Peter has done great work for a long time. -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] beta2 rpms
On Thursday 02 September 2004 16:27, Jon Jensen wrote: > I've been meaning to ask for a long time: Why does /var/log/pgsql get > installed with the execute bit set? I don't have any other log files with > the execute bit on, and can't imagine why that would be necessary or > useful. Am I missing something? H I've set the wrong permission mask in the %files list, apparently. > Also, is there a reason that the init script defaults to redirecting > stdout and stderr to /dev/null instead of to /var/log/pgsql? The intent was t use syslog. The new log rotation scheme will likely be tapped this time around, though. > If the DBA > doesn't turn on logging in postgresql.conf, then very little output goes > to /var/log/pgsql, usually of an important nature like "stopped" or > "started" at a certain date. I normally change that first thing after a > new install. Normally the first thing I do is enable and set up syslog support. This way I can use my established syslog infrastructure, where really important log messages not only get logged to disk but get PRINTED. Logs that print are difficult for intruders to mess with, and once one has an established syslog server it's trivial to send all logs from all servers to the one central logging server. I have done this a long time. -- 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: [HACKERS] beta2 rpms
On Thursday 02 September 2004 00:20, Joe Conway wrote: > I just posted a source rpm for beta2, along with binary rpms for > fc1-i386, fc2-i386, and fc2-x86_64. > http://www.joeconway.com/postgresql-8.0.0beta/ > BTW, I've been naming these similar to the "official" rpms (e.g. > Postgresql-8.0.0*PGDG.*.rpm) mainly just to be consistent. No one has > complained about it, so I take it that's OK? Sorry, I've been kindof swamped around here. Please name them using, say, a 'JC' instead of 'PGDG' if you don't mind. I appreciate you providing these; however, I do intend to be releasing RPM's soon, but probably not beta2 ones. I have some features I want to work on first, and just simply have not yet had the time to do it. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Win32 release warning
On Thursday 26 August 2004 12:56, Bruce Momjian wrote: > Marc G. Fournier wrote: > > "Altho tested throughout our release cycle, the Windows port does not > > have the benefit of the years of testing that has gone into the Unix > > platforms, and, as such, should be treated with the same level of caution > > as you would a new product" > Wow, that is good! > Should I change it to Marc's version? As long as 'although' is correctly spelled :-) -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Is "trust" really a good default?
On Monday 12 July 2004 17:10, Merlin Moncure wrote: > IMO, forcing su password at initdb time (allowing blank password with a > very stern warning) and bumping localhost to auth is the right way to > go. As far as RPM's, etc. I don't think RPM considerations should be > driving security concerns. FWIW, the RPMs default to ident authentication, and trust is off. This is however done as a patch to the sample pg_hba.conf. A command line switch to initdb to mung up an ident default would be fine with me, though. -- 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 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: Release planning (was: Re: [HACKERS] Status report)
On Tuesday 13 July 2004 17:12, Marc G. Fournier wrote: > ... there is alot of stuff that doesn't require a reload of the database > (or initdb) that could very easily be backpatched ... > As Jan points out, its the 'small features that are done' that we've been > griping about having to wait for, not the big ones which we know aren't > done ... Split the feature out into either a patch or a module and put it in contrib until the next major version. Let contrib hold the smaller, non-initdb-forcing patches and such until the next major version rolls them into the mainline. Or even a patches tree parallel to contrib. Either way, the patch or module or whatever wouldn't be in the mainline unless the user needed it. Or maybe we need to rethink what a major version is. But even minor things can force an initdb, although we're better than we have been about this. But Tom's assertion is true. We have enough trouble getting patches rolled out; adding parallel branches is just begging for trouble, due to our relatively small resource size. Although, we probably have enough developers at this point to make it happen. Bruce I would want to be the patchmeister for the stable branch. Someone else (with Bruce's oversight, or Tom's, or whoever) could do the patchmunging and review for the development tree. But I want a stable hand on patches that go into the stable tree. The BSD's release something like that, with CURRENT, TESTING, and STABLE, right? (I'm not a big BSD user...) The Linux kernel has parallel development, and a gatekeeper for each stable release (2.0.x, 2.2.x, 2.4.x, and now 2.6.x). A 2.0.x kernel release happened not too long ago, in fact. We probably could have enough volunteers to do something like that. Gatekeeping a stable release would not be as complex as developing the new release, but, again, I would want an experienced hand on the last stable release where the temptation of backporting 'features' is great. I think a gatekeeper for 7.2.x, for example, would have very little to do except once in a great while if and when a serious bug is found. At that point, that gatekeeper can make a release (the current process is too tied up in people, IMO, and that includes the RPM mechanism (which I have every right to criticize!)). -- 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 8: explain analyze is your friend
Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004
On Saturday 05 June 2004 10:13, Andrew Dunstan wrote: > Lamar Owen wrote: > >There is a reason I wrote the message a long time ago (that, I think, is > > still in the Developer's FAQ) about how to get started in PostgreSQL > > development. The first thing a developer should do before getting too > > involved in the process is to get a feel for the development culture. > If it were true that June 1 was the expected Beta data, then perhaps > that should be in the FAQ too, as a counterweight to the gratuitously > patronising advice which, had I followed it, might have resulted in my > not making a number of contributions. I'm sorry you consider the advice to be 'patronizing' : I can assure you it is not meant that way. It was written from the point of view of someone who had been around the block and had seen how things work (and in my case one who did not do it that way, and regrets it). And I don't think I ever recommended not coding while just reading mailing lists; rather, it should be a hand in hand process: you learn the code while you learn the community. > All I have asked for is a) reasonable clarity and b) reasonable notice. > I do not see that either of those conflict with being laid-back or > anything else above. As Marc said, that is certainly something that could use work, since we have never really been clear in dates: primarily because we never have met them. Please lighten up, that's all. That's one thing I have found helps in this project, and maybe it's not something I made clear, but we are 'laid back' including a fair amount of humor. A good portion of that goes on privately; I remember ribbing Bruce a couple of cycles back with some Biblical references about the signs of the times (he was in 'let's go back through the mailing list a few weeks and pick up TODO items and patches' mode, and I commented that it must be time for beta, due to the signs of the times.). The lesson of the history of our beta 'freezes' is that the permafrost tends to be thin early in the beta cycle, and gets progressively thicker as the cycle progresses. And we have never met the early dates, as evidenced by Peter Eisentraut's desire to see us freeze in March (which obviously did not happen). And my advice is to simply get some context about the process. One gets context of the code; one should apply the same effort to getting the context of the process. With PostgreSQL the code is large and it takes considerable digging to really get into contributing mode; it takes similar amounts of digging to merge into the process. Is this a wrong thing to do? And your contributions are very appreciated, by me in particular. Fresh code ideas, properly applied, are always welcome. -- 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: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004
On Tuesday 01 June 2004 22:15, Andrew Dunstan wrote: > Lamar Owen wrote: > >Well, it should not have surprised anyone. We have targeted June 1 as a > > beta freeze date for several versions, not just 7.5. In fact, looking > > back through last year's pre-7.4 discussion, it's deja vu all over > > again > I confess that as a newcomer I was not around before the 7.4 cycle, so > saying that people should have known the freeze date because it is > following past patterns doesn't help me much. Are people supposed to > obtain this info by trawling mailing list archives years back, or by > some sort of divine revelation? Other OS projects manage this whole > process better, IMNSHO. I'm not trying to point fingers, but to get > future improvement. There is a reason I wrote the message a long time ago (that, I think, is still in the Developer's FAQ) about how to get started in PostgreSQL development. The first thing a developer should do before getting too involved in the process is to get a feel for the development culture. The PostgreSQL development is not like other open source projects, and does depend to some extent on tradition and precedent. So skimming through the archives and following [HACKERS] for six months is really required before getting seriously involved in the process. You need to see how the process really is handled, and to see how the 'Release Manager' and 'Patch-o-matic' get in gear late in the cycle. The pieces really do fit together, we really do have somewhat of a project management structure, but we are really laid-back in our approach. This is the culture of this project, and I for one don't think it should change. It certainly has worked this far. One doesn't just start writing code for a project this size. Having said that, I don't know very many who have actually followed that advice :-) But following through a cycle or two in the archives provides ample evidence for the 'laid-back' model used here. It's ready when it's ready. We try to schedule, but the schedules are pretty flexible. And while most discussion happens here on [HACKERS], not all of it does. Some happens on IRC, some in [CORE], and some by telephone. And it's been that way for a while. PostgreSQL is not a 'release early, release often' project. And that's OK. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Official Freeze Date for 7.5: July 1st, 2004
On Tuesday 01 June 2004 16:08, Simon Riggs wrote: > The June 1st date was first mentioned on list in mid-March (to me), but > wasn't generally announced until May under a specific heading. If it was > set in January, I was never knowingly party to that info. Well, it should not have surprised anyone. We have targeted June 1 as a beta freeze date for several versions, not just 7.5. In fact, looking back through last year's pre-7.4 discussion, it's deja vu all over again Please read the thread "Release cycle length" ( http://archives.postgresql.org/pgsql-hackers/2003-11/msg00889.php ) and follow it through. We're following the same track we did with 7.4. Are we going to be a full year this time? (4.5 months from freeze to release last time) But I could not find using the archives the date June 1 (except in relation to the 7.4 freeze for 6/1/2003). The closest to such a discussion would have been in the thread http://archives.postgresql.org/pgsql-hackers/2004-01/msg00273.php, at least that's all I could find. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Call for 7.5 feature completion
On Tuesday 18 May 2004 21:58, Joshua D. Drake wrote: > > So you then have to build PHP twice, in an RPM build environment. You > > mean I can't just have the headers installed to build plPHP? So, follow > > the > No you need to make sure that PHP is available as a shared lib. Which requires you to build PHP. PHP is only going to get built once; do you build with or without PostgreSQL client support? As an RPM builder, you cannot build it one way, then rebuild it again another way. It's not self-hosting at that point. > > Try building the RPMs for PHP plus PostgreSQL and plPHP, then tell me how > > you solved the circular dependency. > Actually plPHP doesn't require the PostgreSQL source tree... you would > just have to modify the Make file to point to the right places. Then it can easily be a standalone project, and the issues go away. -- 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 8: explain analyze is your friend
Re: [HACKERS] Call for 7.5 feature completion
On Tuesday 18 May 2004 17:33, Joshua D. Drake wrote: > > But most binary packages do, and they are the ones I'm talking about. > > And surely you do not advocate that, in order to build PL/PHP, the > > packagers instead disable the client side support in PHP? > Of course not, but I still don't see your point. plPHP doesn't need > PHP+PostgreSQL support. Nor does PHP+PostgreSQL conflict with using > plPHP... > PHP doesn't even need to be installed for plPHP to work... You just > need the source tree for building. So you then have to build PHP twice, in an RPM build environment. You mean I can't just have the headers installed to build plPHP? So, follow the sequence of the RPM building events: 1.) Build PHP without PostgreSQL client support. 2.) Build PostgreSQL 3.) Build plPHP 4.) Build PHP with PostgreSQL client support. The Perl situation is totally different, since the Perl client is not part of the Perl source tree. The 4-step I mention above would never be followed by any distributions, who would probably just not build plPHP to keep from having the circular dependency. See, in the RPM build environment for self-hosting distributions, I would have to pull in the entire PHP source distribution during the PostgreSQL build. Keeping that synchronized with the PHP version that is the main one distributed would be a major pain. Better would be getting plPHP so that it doesn't need the PostgreSQL source tree, but just needs the development headers (with server-side) installed. Then there is no circular build dependency. Then I just: 1.) Build PostgreSQL 2.) Build PHP (with PostgreSQL client support) 3.) Build plPHP (with PostgreSQL SPI support, or maybe even PostgreSQL client support for cross database queries? :-)) Try building the RPMs for PHP plus PostgreSQL and plPHP, then tell me how you solved the circular dependency. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Log rotation
On Saturday 13 March 2004 01:00 pm, Fernando Nasser wrote: > There are some applicatons which run in servers with very strict > response times and any syscall, network packet that can be saved counts. Ok, what about pipe overhead? If we're gong to split hairs, let's split all of them. The design of the pipeline in this logrotator filter will have to be such that minimal overhead occurs, because, at the real-time level, every concurrent process also counts. > The number of generated messgaes. > Maybe that is an area that can be worked on, i.e. reducing log > verbosity. Is 7.4.x much better than 7.3.x in that respect? There are several levels documented in postgresql.conf. Try the terse level and see what happens. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Log rotation
On Saturday 13 March 2004 10:36 am, Fernando Nasser wrote: > The problem is that sysloging has more overhead than a plain append to a > file. There are some very strict response time AppServer applications > where we want to keep this things out of the picture. Well, I have a couple of ideas on that. First, a better syslog. SDSC secure syslog has been available for some time and is BSD licensed, and is specifically designed for high-performance RFC3195 compliant secure syslog. Second, if the syslog server is separate, then you might get better performance as the size of the logs grow, since appending a very large file is slower than generating an IP datagram. Third, it seems that you don't have enough profiling data to support a 'syslog is bad' position. Java is bad too, from a performance standpoint (at this time, at least, you always get a performance hit of some kind using any portable code). But if this AppServer is based on the ArsDigita Java codebase, you have other performance issues already (the Tcl codebase, OTOH, is very fast, partly because AOLserver is a faster appserver than most Java appservers).). > The other problem is that we have some nice graphical tools for > configuring logging but the /etc/syslog.conf is a very hard one to > automate dur to the pattern matching. We can add some lines there, like > one to get local0 to a specific file, but it will probably be guesswork > and require human inspection anyway. Control Center looks promising. But I much prefer having a central syslog server than having each server in a cluster having separate logs. > It may be desirable to logrotate them at different times as well, so > they would have to be in different files. Different facilities can then go to different files. The problem, of course, is syslog's limited number of facilities. > > Or you'll have to include some other log rotator. > That is what Tom is proposing. I am not opposed to including a small logrotator for stderr logging. I just think it is redundant when a good highly configurable logging facility already exists. But, if Red Hat wants to pay Tom to do it... :-) -- 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 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: [HACKERS] Log rotation
On Friday 12 March 2004 03:21 pm, Fernando Nasser wrote: > Lamar Owen wrote: > > Uh, we have many many many different ways to use syslog. So my other > > message on the topic. > Which other message? The one I didn't post. :-) > Anyway, Syslog is not an option for us. We need flat files. Ok, riddle me this: If I have PostgreSQL set to log to syslog facility LOCAL0, and a local0.none on /var/log/messages and local0.* to /var/log/pgsql (assuming only one postmaster, unfortunately) then you get a flat file. I can see that in a multipostmaster setting how you might want some differentiation between postmasters, but ISTM that the tool reading these logs should be trained in how to separate loglines out. I use a product called SmoothWall as a firewall/VPN solution, and its log reporting modules split out loglines in this way, so that I can have the ipsec logs in one browser page and the l2tp logs elsewhere, and the ppp logs elsewhere, and the kernel logs elsewhere Or you'll have to include some other log rotator. > > Uh, upgrading? I'm sure we have more reports about upgrading than > > logging. > Yeah, but that only comes with a full version upgrade :-) Which is quite often. And people tend to upgrade as part of the OS upgrade, which could easily be every other version (in the case of Fedora). Upgrading from RHAS 2.1 to RHEL3 (I know it's not supported) should prove to be an interesting one. > The logging one keeps popping up as people try and use the server for > production. Yes, and for the vast majority of cases syslog is enough solution for the job. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Log rotation
On Friday 12 March 2004 09:24 am, Fernando Nasser wrote: > I don't really care on how its done, but IMO an enterprise class > database must be able to do log rotation. Logging to Syslog is not an > option (specially with our verbosity) -- users must be able to use flat > files for logging. Uh, we have many many many different ways to use syslog. So my other message on the topic. > I never seem some many customer complaints and bug reports about a > single item like the ones we have received here about logging. I think > this should be the number 1 item in te TODO list. Uh, upgrading? I'm sure we have more reports about upgrading than logging. But see my reply to bug 103767 for more. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Sigh, 7.3.6 rewrap not right
On Friday 05 March 2004 09:50 am, Mark Gibson wrote: > How about in future, packaging it all up as a release candidate, > (ie. 7.4.2-rc1) for a week or so before official final release, We do this already for major versions. Maybe we should consider this for minors too. -- 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: [HACKERS] Sigh, 7.3.6 rewrap not right
On Thursday 04 March 2004 10:28 pm, Tom Lane wrote: > There were no code-change differences in this rewrap, so I see no real > need to change the version number. > The lesson I'd prefer to see us take away from this is that Marc needs > to automate his release wrapping process more. These sorta mistakes > shouldn't have happened in the first place ... There are now multiple copies of 7.3.6 out there. How is a body to know which one to use? On RPMs, as you well now, SOP is to increment the release on any change, including a typo. This way there is no ambiguity. This is not the first time tarballs have been streamlined. I'm glad I hadn't built any RPMs yet. -- 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 8: explain analyze is your friend
Re: [HACKERS] Sigh, 7.3.6 rewrap not right
On Thursday 04 March 2004 07:45 pm, Marc G. Fournier wrote: > Okay, I've repackaged it, and temporarily put everything into > /pub/source/v7.3.6_1 ... if ppl can confirm that I haven't somehow missed > something again (I rm -rf'd the old build tree and re-cvs exported it, so > it started clean), I'll move those files over to 7.3.6 ... Please, don't call it 7.3.6. Streamlining releases is terrible. 7.3.7 or 7.3.6.1 or SOMETHING other than 7.3.6, and just let 7.3.6 be a brown paper bag release (like 6.4.1 was). -- 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 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: [HACKERS] Heads up: 7.3.6 and 7.4.2 coming soon
On Sunday 22 February 2004 05:57 pm, Gaetano Mendola wrote: > Do you think that we'll have too a RPM binary distribution for the 7.3.6 > ( the 7.3.5 don't have it yet ) ? Yes. I apologize for the lag; my wife miscarried and that has thrown my free time for a loop as I help her and my other four children through this difficult time. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Old binary packages.
On Tuesday 20 January 2004 01:36 pm, Peter Eisentraut wrote: > But where are the spec files and other stuff that belongs into the old > RPMs? Just the source releases are not enough if someone needs to deal > with old systems. And since you mentioned it, creating a source > tarball from CVS does involve human factors and cannot be repeated at > will. I am willing to make up tarballs of the specs, patches, and scripts that were used for each source RPM. Or just leave the source RPM ready to rebuild in place; just getting rid of the precompiled stuff. Looking at the directory listing that is there right now: v7.0v7.1v7.1.2 v7.2v7.2.2 v7.2.4 v7.3.1 v7.3.3 v7.4 v7.0.3 v7.1.1 v7.1.3 v7.2.1 v7.2.3 v7.3v7.3.2 v7.3.4 v7.4.1 (oops, that reminds me that I need to roll 7.3.5 packagesargh) I would look at removing: v7.0v7.1v7.1.2 v7.2v7.2.2 v7.3.1 v7.3.3 v7.1.1 v7.2.1 v7.2.3 v7.3v7.3.2 which would leave: v7.2.4 v7.4 v7.0.3 v7.1.3 v7.3.4 v7.4.1 And there's nothing there prior to 7.0. I can, if demand arises, resurrect the 6.5, 6.4, 6.3, and 6.2.1 binaries. But there are serious bugs in some of those versions; keeping them up really doesn't serve a purpose: why would we want precompiled binaries for 7.2.2, for instance? > Some people are still using 7.2, for example, and the first thing you > want to do if you go there is upgrading to the latest 7.2 release. By > removing the binaries without any pressure you're just throwing > obstacles in people's ways. I for one will have to make a full mirror > pretty soon because I do need those old files. I would leave the last minor of each major in place, just removing the minors we know to be buggy. So, to use your example, 7.2.4 would be there for the 7.2.x users still among us. And this wouldn't touch the source releases at all. -- 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: [HACKERS] Old binary packages.
On Monday 19 January 2004 03:53 pm, Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > I am looking at the possibility of cleaning up the binary tree on the ftp > > site, and was wondering what the group thought about purging old > > binaries. What I was thinking would be to remove all but the last minor > > release of each major version. Thus, I would remove 7.4, but leave > > 7.4.1. > I concur with Josh Drake's thought --- leave releases that are less > than, perhaps, six months old, even if they have been superseded in > their series. Superseded releases that are older than that could be > dispensed with. I'm gong to wait a day or so to see what other input comes through, but this is the way I'm currently leaning. I will make a full mirror of what is there now on my own box, and then if somebody screams loudly I can restore things. While disk may be cheap, it ain't so cheap that wasting it is a good thing. With the source releases still available way back, havng binaries that old, while useful to some, is not IMO in the best interest of all. -- 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 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
[HACKERS] Old binary packages.
I am looking at the possibility of cleaning up the binary tree on the ftp site, and was wondering what the group thought about purging old binaries. What I was thinking would be to remove all but the last minor release of each major version. Thus, I would remove 7.4, but leave 7.4.1. The space taken by binaries is significant (about 1GB at this point). Since we are keeping all source releases (although I would question that, since we use CVS), keeping all the binaries around is just a space waster, IMHO. Comments? -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Little mess in RPM RH ?
On Sunday 28 December 2003 09:03 am, Gaetano Mendola wrote: > Sander Steffann wrote: > > This is because when I built the RPMs for RedHat there were little > > differences between the different RedHat releases that caused the builds > > to fail. I had to make minor adjustments for each platform, which is why > > there are so many different release versions. The contents of the RPMs is > > identical, only the build instructions differ. The SRPMs for all these > > versions are at http://opensource.nederland.net/PostgreSQL/. > Gasp! Another site popped up ! Why aren't these SRPMs in an official > Postgresql site ? They are. See ftp://ftp.postgresql.org/pub/binary/v7.4/redhat/redhat-6.2/postgresql-7.4-0.4PGDG.src.rpm as an example. Sander hosts his own site; and that's OK. I did the same back when I first got started do this from my own server. Then Marc allowed me to directly upload. > I'll do it tomorrow, or is may be better do it for the 7.4.1 ? If you'll hold off a few days both 7.4.1 and 7.3.5 RPMs are due to be released. At that point building on various distributions and setting up torrents will be done. -- 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: [HACKERS] Little mess in RPM RH ?
On Saturday 27 December 2003 08:02 pm, Gaetano Mendola wrote: > I'm founding little messy the RPM condition for redhat: Yes, it is a litle messy. My apologies. There will hopefully not be that with the 7.4.1 set that I hope to release when I get back from vacation (Saturday or Monday, depending). > I'm able to put my hand on RH 8.0, RH 9.0, RHAS 2.1 and RHAS 3.0 > and RH 7.3 systems, if you need some help let me know. Sander Steffann has been building for most of those, except RHEL AS 3. I have an installed WBEL (White Box EL, a 'generic' linux distribution built from the SRPMS that Red Hat has in its enterprise directory). That box isn't a devel box, but I am building up (while I'm on vacation) a devel box. So I'll be building RPMs on that box with WBEL which should install on RHEL3. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] rebuilding rpm for RH9 error
On Thursday 04 December 2003 02:29 pm, Gaetano Mendola wrote: > I did it on a RHAS 2.1 > and I get: For RHAS 2.1 you need to tell it that you are running Red Hat 7.x (--define 'build7x 1') Which I think disables the plperl build (but don't quote me on that). I'm working on making this automatic; in fact, I have delayed release of the 7.3.5 RPMset because of this. I'd love to check it out with 7.3.5. (however, real work keeps getting in the way today; it may be a tonight thing, with the upload to happen tomorrow). -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] rebuilding rpm for RH9 error
On Tuesday 02 December 2003 06:29 pm, Gaetano Mendola wrote: > Lamar Owen wrote: > > You need to specify that you are building for Red Hat 9 on the command > I'll try. Ok. > PS: the 7.4 will be remembered as the longest release to be developed > and for the longest period needed in order to have the RPM for RH. Not quite. The reason I got involved in this is the lag in getting 6.5 RPM's way back when. As well as 6.4 and prior. Prior to 6.5 it would have been possible to have six months between release of a tarball and release of an RPM, usually by Red Hat itself. I think I was slower with 7.1.x, but that was due to a different reason. > Good job anyway. Well, thanks, anyway :-) No, seriously, I must be doing ok if the longest time to RPM release for the final release was just a week or so. That's not too bad, really. But I do try to get closer to the release, and not farther. And I will try to get 7.4.1 and 7.3.5 RPMs out sooner. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] rebuilding rpm for RH9 error
On Monday 01 December 2003 08:53 pm, Gaetano Mendola wrote: > Hi all, > I'm still experiencing problem trying to > rebuild the rpm from the file: > postgresql-7.4-0.5PGDG.src.rpm > I seen that the configure is done with: > --with-krb5=/usr. You need to specify that you are building for Red Hat 9 on the command line. The command line argument would be: rpmbuild --define 'build89 1' --rebuild That command line passes --with-krb5=/usr/kerberos to configure (which unfortunately will have to change for next cycle, but that's a different problem). Red Hat 9 and earlier put the kerberos stuff under /usr/kerberos; Fedora Core 1 puts it under /usr. My source RPM is being developed currently on Fedora Core, which is what I run on my laptop. > I also try to install the RPM already builded but I obtain: > file /usr/include/sqltypes.h from install of > postgresql-devel-7.4-0.5PGDG conflicts with file from package > unixODBC-devel-2.2.3-6 There is a namespace collision between the unixODBC includes and the PostgreSQL includes. It is being looked at; one or both will have to move the include to somewhere else. So, at the moment, you can't have unixODBC-devel and postgresql-devel installed at the same time. I am investigating the best way of correcting this without breaking too many things. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] -fpic vs. -fPIC
On Saturday 29 November 2003 01:07 pm, Tom Lane wrote:
> Lamar Owen <[EMAIL PROTECTED]> writes:
> > The project lead for the Aurora SPARC Linux project is who recommended it
> > in the first place;
> We were told equally positively, by equally well-informed persons, that
> we should prefer -fpic if at all possible.
And the why is?
> The best I have been able to tell is that none of our .so's are anywhere
> near large enough to require -fPIC. In the absence of any evidence that
> we really are near the threshold, I'd prefer to go for the
> better-performing alternative.
Ok. As I don't have a SPARC running a gcc 3 built distribution, I can't
really check. When the next version of Aurora comes up, we may have some
data points. Until then I can only take Tom Callaway's word for it. He'll
probably patch it out anyway for the Aurora distribution, so it'll only
impact from-source builds anyway.
On my Aurora 1.0 box, the number (given by the line Jakub mentioned) is
0x000560 for libpq.so.3.1, so we're not up there yet. On my Fedora Core
Intel box, libpq.so.3.1 has the number 0x000414, so the SPARC version does
require a larger GOT. This is on Aurora 1.0, though, which is built with gcc
2.96.
So, no, -fPIC does not appear to be required for libpq. OTOH, plpython is
getting closer, with 0x001B70 being printed (0x002000 being the threshold).
On Intel, plpython gets a 0x000E08. So on SPARC plpython at least has a much
larger GOT. And the size of the library is no indication at all as to how
big the GOT is. PL/Python appears to have by a large margin the largest GOT
of the shared objects we ship. If the error is noticeable with -fpic in
place, then it seems to be ok to do this.
Command line to find out:
readelf -WS $SONAME | sed -n 's/^.* \.got.*PROGBITS//p' | awk '{ print $3 }'
--
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 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] -fpic vs. -fPIC
On Friday 28 November 2003 12:31 pm, Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > I've tried building PostgreSQL with -fpic on Sparc and saw no problems.
> > So I suggest that we change back to -fpic until we get detailed evidence.
> Okay with me. It never struck me that we'd really seen adequate
> evidence that -fPIC was needed.
> Makefile.solaris is the only other place where gcc -fPIC is selected;
> should it be changed also?
If it is in Makefile.solaris, we would need to think about it, IMO. -fpic is
not guaranteed to work properly on SPARC; -fPIC is. There was a reason it
was put in Makefile.solaris, I'm sure. Tracing its lineage shows it was in
the very first template for Solaris.
The project lead for the Aurora SPARC Linux project is who recommended it in
the first place; lessee, the last word we had on the subject was from Jakub:
>On Wed, May 21, 2003 at 10:15:19AM -0400, Tom Lane wrote:
>> Jakub Jelinek <[EMAIL PROTECTED]> writes:
>> > readelf -WS thelibrary.so | sed -n 's/^.* \.got.*PROGBITS//p' | awk '{
>print $3 }'
>> > If the printed number is bigger than 0x2000, you need -fPIC, otherwise
you
>> > should use -fpic.
>>
>> Ah-hah. And I would imagine that this number depends only on the number
>> of global symbols used in the library, and therefore will be the same on
>> every arch?
>
>Nope, it may differ accross arches (and not only because 32-bit vs. 64-bit,
>but on SPARC e.g. because there is no GOT relative relocation, so even
>static int i; int *foo (void) { return &i; } needs to allocate a .got slot
>for i.
>
>Jakub
So, just because -fpic could work now is meaningless. It could break silently
in the future, for random .so's. It would depend on the specific .so; get
one that's large enough and you break. It is SOP for the Aurora Linux
distribution to use -fPIC for all .so builds, IIRC. But testing of the GOT
size would be needed on a .so by .so basis to make sure that everything
worked. And it might work for one compiler version and not another; Aurora
Linux currently is built with gcc 2.96, but the move is afoot to go to gcc 3
and be Fedora Core based.
So, I ask, why change something that is going to work every time to something
that may very well break silently in the future? (yes, I know about the
performance difference; is the increased performance worth the tradeoff?)
--
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 8: explain analyze is your friend
Re: [HACKERS] Updates for RPMS.
On Monday 24 November 2003 03:34 pm, David Fetter wrote: > I just tried building 0.3PGDG on Redhat 9, and got: > # rpmbuild --rebuild postgresql-7.4-0.3PGDG.src.rpm > [snip] > checking krb5.h usability... no > checking krb5.h presence... no > checking for krb5.h... no > configure: error: header file is required for Kerberos 5 > error: Bad exit status from /var/tmp/rpm-tmp.97860 (%build) > [snip] > Is there some way to tell the .spec file where to look for krb5.h? Yes. Try rpmbuild --define 'build89 1' --rebuild postgresql-7.4-0.3PGDG.src.rpm I'm looking at automating this; but at the moment it is manual. The spec file does check the build89 macro, and, if defined, throws in the right value for kerberos. -- 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
[HACKERS] Updates for RPMS.
Sander Steffann has built Red Hat 6.2, 7.3, 9, and RHEL 2.1 RPM's for me, and I have uploaded them. The release is different; 0.3PGDG and 0.4PGDG. I will be looking at his spec file differences and updating the source RPM soon. The binary RPM for Fedora will remain at 0.2PGDG for now. If you have Fedora 1, Aurora 1.0, or Red Hat 8.0, you may continue using the 0.2PGDG set: for these distributions nothing has changed. The only change is in the building of the RPMs for Red Hat 6.2, 7.3, 9, and RHEL 2.1. A 1PGDG RPMset should come soon, once I see what Sander has done. This will just be spec file changes, probably, unless another bug appears in the initscript. -- 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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] First generic/redhatish RPM's uploaded to ftp.postgresql.org.
On Friday 21 November 2003 01:13 pm, Lamar Owen wrote: > I have uploaded a first cut at the RPM's to ftp.postgresql.org. While I am > not 100% convinced of the need to do so, I have restructured the > directories, and await comment on that. > I expect RH 7.3, RH9, and RH 6.2 packages shortly from Sander, once he > reads this mail and gets the time to build them, as he has already asked to > help do this. I have RH 8.0 at my disposal, and will build those. I will > also be building Aurora 1.0 packages. Aurora 1.0 and Red Hat 8.0 source and binaries are uploaded. The source RPM has changed a little for each of these, which is noted in the release tag; I have some work to do in the specfile portability, which I will do soon. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] First generic/redhatish RPM's uploaded to ftp.postgresql.org.
I have uploaded a first cut at the RPM's to ftp.postgresql.org. While I am not 100% convinced of the need to do so, I have restructured the directories, and await comment on that. Currently the upload is for Fedora Core 1 only. The source RPM should compile on most recent Red Hat's and close cousins. See ftp://ftp.postgresql.org/pub/binary/v7.4/fedora for the SRPMS and fedora-core-1 directory. As I build the set on other distributions, or as others do so, I will create the appropriate directories and will link the SRPMS dir in each of those to the fedora/SRPMS dir, since that is the master source RPM. Please read README.rpm-dist, found in the postgresql-7.4-0.1PGDG.i386.rpm file, or unpacked in pub/binary/v7.4/fedora, for more details. This set is similar to previous sets in many respects. This is not what I wanted; I wanted to restructure the whole shooting match in concert with Oliver's Debian package restructure. The fewer differences the better, and many parts of Oliver's proposal I plan on implementing in the RPMs verbatim. However, when Oliver released the 7.4 deb without those changes, and due to the SuSE RPM's release, I decided to go ahead with it. Kaj's posting of the patches against the 7.3.4 specfile was a tremendous help in this regard, many thanks Kaj! There were problems, but it was an excellent starting point. There are a few outstanding patches and bugs I need to fix; thus, this RPMset has an 0.1PGDG release tag. I have been somewhat ill this week; maybe by next week I can close some bugs and get us to 1PGDG. Even though the python client is no longer included in the main tarball, thanks to Kaj we have not lost the python subpackage. I expect RH 7.3, RH9, and RH 6.2 packages shortly from Sander, once he reads this mail and gets the time to build them, as he has already asked to help do this. I have RH 8.0 at my disposal, and will build those. I will also be building Aurora 1.0 packages. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] A big thanks to SuSE
On Wednesday 19 November 2003 12:02 pm, Peter Eisentraut wrote: > Lamar Owen writes: > > And he is getting paid to do it, unlike me. > > That's news to me. :-) Reinhard Max is getting paid to do it, not you. Bad english on my part. -- 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 8: explain analyze is your friend
Re: [HACKERS] A big thanks to SuSE
On Monday 17 November 2003 05:28 pm, Daniele Orlandi wrote: > Yesterday I was a bit worried... I switched to SuSE just 2 weeks ago... > my newly installed databse server was waitinI thought that I would have > to wait so much to have RPMs for SuSE and today I see v7.4 compiled for > many flavors of SuSE, even for X86-64. Wow :) Reinhard Max does good work. SuSE is different enough from Red Hat-style distributions to where my packages historically didn't fit well within their framework, so they have typically done their own thing. Apparently Peter is working with them at this point, which is good for PostgreSQL. And he is getting paid to do it, unlike me. -- 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: [HACKERS] rpm support for 7.4 and beyond
On Thursday 13 November 2003 12:09 am, Matthew T. O'Connor wrote: > On Wed, 2003-11-12 at 23:44, Lamar Owen wrote: > > My hands are somewhat tied at the present to only supporting what I > > actively run. That is currently RHL 8.0 and Fedora Core 1. (not 1.0, > > incidentally; there is no minor version). > Have you tried mach? http://thomas.apestaart.org/projects/mach/ > I know it is used successfully by several 3rd party rpm packaging sites > such as freshrpms.net. Also, it's very easy to setup. Yes, I am familiar with mach. It's not for lack of hardware, or even disk space. It is simply that I cannot in a clear conscience support distributions I don't actively run (I forgot one distribution I actively run, and that's Aurora SPARC Linux (currently at 1.0, which is roughly equivalent to Red Hat Linux 7.3)). So even if I did have a box running, say, RHL 7.2, for the express purpose of building RPMs, I would be uncomfortable supporting this since I no longer use RHL 7.2 actively. I had in the past thought I would do so, but then people expected more than I could deliver. And so the current situation is that people who actively use older dists build it and support it for those dists. -- 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 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: [HACKERS] rpm support for 7.4 and beyond
On Wednesday 12 November 2003 11:51 pm, Marc G. Fournier wrote: > On Wed, 12 Nov 2003, Lamar Owen wrote: > > The biggest issue is going to be 'will it build' on those releases. > > The tcl version deal (with tcl prior to 8.1) > Tom applied a patch so that the build will continue to work on 8.0.x ... > or is this some other issue? Oh, did that patch get applied? I saw it float by the list, but didn't know what the disposition was (since I don't follow -committers). -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] rpm support for 7.4 and beyond
On Wednesday 12 November 2003 08:57 am, Robert Treat wrote: > I haven't seen any discussion on the topic, so thought I might start > one. We currently provide rpms for Red Hat 7.x, 8.x, and 9, and I'm > assuming that we'll have rpms for all of those for 7.4 once release time > rolls around. However, given that Red Hat is dropping support for 7.x > and 8.x version on Jan 1st, and Red Hat 9 next April, do the current rpm > builders forsee any issues with providing rpms for those platforms in > the future? The biggest issue is going to be 'will it build' on those releases. The tcl version deal (with tcl prior to 8.1) will prevent building on Red Hat 6.2 (which we have tried to support, to varying degrees). I am following the Fedora Legacy project; they purpose to support as a cummunity those older RHL releases. My hands are somewhat tied at the present to only supporting what I actively run. That is currently RHL 8.0 and Fedora Core 1. (not 1.0, incidentally; there is no minor version). I am migrating to Fedora Core 1 across the board, and will be migrating to FC 2 when it comes out (I need the 2.6 kernel's features). While I could easily install and build up a buildfarm for the others, if I'm not actively using it bitrot is more likely to set in. But as part of Fedora Legacy I may be doing this anyway. Depends on the business case I can make for it at PARI. Frankly, supporting the older stuff is a real pain, primarily because people expect an rpm -Uvh to work in a sane manner, which it currently does not do. That, BTW, is why there haven't been any RPMs of 7.4 yet: I plan on having a migration strategy in place first, although if I can't get it working right by final I may just provide the same sort of RPM as prior. The idea is to have 7.2.4 and 7.3.[45] RPMs with the migration strategy built in concurrently to the 7.4 RPMs -- this way, the user can update to the same major version first, then _install_ (NOT upgrade) the 7.4 RPM on top. This works with the linux kernel now; it shouldn't be too hard to make it work with postgresql. > Also (and maybe someone from Red Hat can weigh in here) are there any > plans from Red Hat to release RHEL rpms for postgresql in the future, > and/or plans to make sure the community rpm builders would have access > to those platforms in order to build rpms against them? The RHEL3 beta, taroon, had the rh-postgresql rpms, including the server packages. I am also intrigued by the community-driven rhel-rebuild and cAosity projects. If those stay close to the 'official' thing from Red Hat, then a postgresql rpm built there should run on real RHEL. Having said that, I plan on budgeting for a copy of RHEL WS. I can build there. I have had pretty good results with my volunteer team thus far; I hope that continues. What I do want to ask for, though, is a little patience if the 7.4 release happens with no RPMs concurrently released. I do my best; but I have a job to do. That job is currently very busy. -- 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 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] [ADMIN] postgres 6.2 vacuum
On Monday 29 September 2003 11:41 am, Jan Wieck wrote: > Tom Lane wrote: > > I do agree that people running that old a Linux distro need to think > > about updating more than just Postgres, though. They have kernel bugs > > as well as PG bugs to fear :-( > Plus all the well known vulnerabilities used by worms and root kits ... Assuming the db server is exposed directly to the Internet. I know of old, obscurity-secured systems with none of the development tools necessary to use a rootkit (and rootkits are extremely rare in precompiled form for things that old and uncommon), and running none of the traditionally exploited services. A Red Hat 5.2 server running only PostgreSQL 6.3.2, for instance, can be made very secure without upgrades by disposing of vulnerable services and running the latest and greatest 2.0.x series kernel (2.0.40, IIRC). And once such a server is running on, say, a dual PPro 200 and serving up queries at the design rate, what is the impetus and motivation to upgrade? Furthermore, if one were leery of the SCO business with Linux 2.4.x and later, then one would be running a 2.0.x or 2.2.x kernel based system anyway, where SCO has not made any claims. This brings us back to a Red Hat 5.2 for 2.0.x or Red Hat 7.0 (not 7.1 or later) for 2.2.x. Although Red Hat 6.2 is a safer bet for a 2.2.x based system. Just make sure to update it before connecting it to the Internet, if it is to be connected to the Internet. Or don't run the rootable services that 6.2 has out of the box. 7.3.4 is buildable on 6.2, which makes it a nice balance point for those who want to do this sort of thing. -- 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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [ADMIN] postgres 6.2 vacuum
On Friday 26 September 2003 10:52, Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > This isn't necessarily true. That old of a version of PostgreSQL is > > probably running on a quite out-of-date OS -- for instance, if the OS was > > Red Hat Linux, then the point at which 6.2.1 was shipped was RHL 5.0. > > Can you even compile PostgreSQL 7.3.x on RHL 5.0 or its contemporaries? > Surely. We still support other platforms that make RHL 5.0 look like > the new kid on the block. There might not be RPMs available, but I > can't believe it wouldn't compile from source. I think I tried a 7.1.x on 5.2 a long time ago, and it didn't build for some reason. But that has been some time ago. I might just build up a 5.2 system (plus errata) to see. > I do agree that people running that old a Linux distro need to think > about updating more than just Postgres, though. They have kernel bugs > as well as PG bugs to fear :-( 2.0 happily doesn't have many new bugs, and it is being maintained, IIRC. Just not by Red Hat. -- 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 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: [HACKERS] [ADMIN] postgres 6.2 vacuum
On Friday 26 September 2003 02:29, Shridhar Daithankar wrote: > Well, I am sure there are data corruption bugs fixed between 6.2 and > current CVS head which would count as large impact in terms of numbers and > severity. Indeed there are. > Its not like oracle upgrade where you have to move the OS, hardware and > spend a large amount of money. The impact of migration is restricted to > downtime of servers and cleaning up any applications that depend upon any > incorrect behaviour supported in past. This isn't necessarily true. That old of a version of PostgreSQL is probably running on a quite out-of-date OS -- for instance, if the OS was Red Hat Linux, then the point at which 6.2.1 was shipped was RHL 5.0. Can you even compile PostgreSQL 7.3.x on RHL 5.0 or its contemporaries? I have had this problem, and still, at one client, have a box running PostgreSQL 6.5.3 because later PostgreSQL's haven't been well tested on RHL 5.2. There is a binary-only closed source app running on the box that won't run on even a Linux 2.2 kernel, much less a 2.4 kernel. The 5.2 box is running the latest 2.0.x kernel. That client depends upon behaviors of the older version of that application that the newer version of that application doesn't perform. So they are quite literally stuck at 6.5.3. I would love to get them up to something better, but, it's not at the moment worth enough to them to do it. When the cost-benefit balance swings to the benefit side, things will change. If I could even get the box up to RHL 6.2 I'd be better off, because PostgreSQL 7.3.x builds and runs well there. -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Single-file DBs WAS: Need concrete "Why Postgres
On Friday 22 August 2003 18:42, Josh Berkus wrote: > Bad link. This gives me a post by Lamar Owen talking about usng OIDs to > name files. I think he may be referring to the last paragraph. Vadim had said that the tablenames would go to OIDs. They have always been individual files. Been a long time since I wrote that e-mail.... -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] more fun with 7.3.4 RPMs
On Saturday 16 August 2003 13:52, Andrew Dunstan wrote: > [EMAIL PROTECTED] andrew]# rpm --test -Uhv postgresql-*7.3.4-1PGDG.*.rpm > error: Failed dependencies: > perl(Pg) is needed by postgresql-contrib-7.3.4-1PGDG > [EMAIL PROTECTED] andrew]# > [EMAIL PROTECTED] andrew]# rpm -q --whatprovides 'perl(Pg)' > postgresql-perl-7.2.3-5.80 > [EMAIL PROTECTED] andrew]# It's the wrong version. Install with --nodeps, and then install the current Pg module from gborg.postgresql.org. I'm still waiting for someone to step up to the plate and maintain RPM's for the parts of PostgreSQL that were removed from the main tarball, such as perl. The python client will likewise need a RPM maintainer for 7.4 (IIRC; I saw something about the python client being removed a couple of weeks ago). I think it's the Rserv contrib module that's throwing the dependency into the build. If people can wait a little, I'll try to do it before 7.4 release. (note: no beta RPMs yet). -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries
On Tuesday 05 August 2003 08:14, Andrew Dunstan wrote: > Will check later today. When you do, let me know, so that I can post them. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 7.4 beta binaries
On Tuesday 05 August 2003 03:15, Shridhar Daithankar wrote: > I am willing to build 7.4beta binaries on slackware and upload them > someplace. This is just to add to binary packages readily available. > Can anybody tell me what flags etc. are to be used. I have a slackware 9.0 > installation with most of the developer tools I believe. I can give it a > shot. Ok. If you want LSB-compliant locations, feel free to use the RPM locations as a model; I realize slack is going to have different locations for things. Is there an existing slack .tgz of PostgreSQL 7.3 or even 7.2 to use as a model? If there is, you would want to build it that way; principle of least surprise. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries
On Monday 04 August 2003 13:57, Joe Conway wrote: > I just checked, and the RHAS that I built the RPMs on is pretty close to > original, other than kernel and some driver updates. I'll let you decide > whether to pull them or not, but they don't meet your "fully-updated > install" criterion. Hmmm... Tough call, but I think I'll leave them be, since they will install on a fully-updated installation. Although I can't imagine an RHAS install not updated, but that's a different topic. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries
On Monday 04 August 2003 13:00, Joe Conway wrote: > I don't think so -- the server I built those on is very much vanilla > RHAS. But then this raises a question in my mind -- is vanilla a fully > updated vanilla or "off the original CDs" vanilla? I've thus far used the definition that it is a fully-updated install, using the OS vendor's update packages that are dependencies of PostgreSQL. Updating to, say, a later KDE, or GNUcash, or whatnot is OK. But core libraries that PostgreSQL uses need to stay vanilla-updated. > Sorry -- I'll be more cognizant of that in the future. Hey, don't worry about it. I should have checked: that IS my responsibility. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] problem with RH7.3 Pg7.3.4 binaries
On Monday 04 August 2003 11:53, Joe Conway wrote: > Andrew Dunstan wrote: > > I know building RPMs can be a major pain, but ISTM that builds should be > > published that don't break on vanilla installations. I'm prepared to > > help with fixing this if necessary. For now I've upgraded to 7.3.3 (the > > RPMs for this don't suffer the same problem on RH7.3). > Sorry, that's my fault, not Lamar's. I built the 7.3 RPMs for him. > Unfortunately I don't have a plain vanilla installation available -- I > had forgotten that I upgraded ssl to something non-standard :( > Perhaps if you have a vanilla 7.3 machine available, you could build new > 7.3 RPMs from the source RPM and give them to Lamar for distribution? Until vanilla-built RH7.3 RPMs are available, I've removed them from the FTP site. I don't have an RH7.3 installation readily available for building. Joe, the RHAS binaries won't have this problem, right? To prevent this in the future, I'm going to state that anyone who wants to build RPMs for distribution needs to do so with a fully up to date vanilla installation of the target OS. Since I do this myself for whatever RPMs I'm personally building, it was an easy assumption to make that everyone would do this. My apologies. A minor rant: I seem to vacillate between providing only one set of RPMs versus providing whatever sets people can build for me. There is a definite tradeoff between having lots of sets available and having only good sets available. While I do my best to ensure only good sets are available, I am not able to test every set that is built. That is one reason I've not begun GPG-signing my RPMs -- if you want certified RPMs build them yourself. It isn't that hard. And when people are so impatient for RPMsets, then complain that the set didn't work -- well, it isn't the most encouraging thing in the world. You want guaranteed RPMs that will install on your machine the day of the release? You have three choices: build them yourself, pay someone to build them, or wait until the official set is available. My rate for building RPMs under those conditions is $100 per hour. (and I have been paid that rate before.) But the official set will only get uploaded once I've had the time to build it and test it. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [HACKERS] Upgrading my BSDI box, again
On Wednesday 30 July 2003 15:39, Bruce Momjian wrote:
> Andrew Sullivan wrote:
> > It's yet worse than this. Some IDE drives will respond to the
> > command to turn off write cacheing, but they _don't actually turn it
> > off_. In other words, you think you've done the right thing, and you
> > haven't anyway.
> Is there an interface to control this with IDE drives? I know there is
> scsicmd for SCSI, but I didn't think IDE had any similar interface to
> control the drive.
What Andrew is saying is that on some IDE drives it doesn't matter what the OS
tells the drive to do. According to the Linux hdparm man page, the desired
flag is '-W':
-W Disable/enable the IDE drive’s write-caching feature (default
state is undeterminable; manufacturer/model specific).
--
Lamar Owen
Director of Information Technology
Pisgah Astronomical Research Institute
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] RPMs for 7.3.4, and a change.
Good evening. RPMs for PostgreSQL 7.3.4, built on three architectures, are in the midst of uploading to ftp.postgresql.org, in /pub/binary/v7.3.4/RPMS. As usual, inside that directory is the directory SRPMS, which contains the source RPM, as well as the three binary RPM directories I am uploading. One minor thing; a source RPM suitable for rebuilding on Red Hat 7.3 is available in the aurora-1.0 subdirectory. Aurora 1.0 is basically Red Hat 7.3 for SPARC; there are also SPARC binaries there. Other than the version change, this RPMset includes the correct JDBC jars. There are a couple of fixes that have been e-mailed to me that are not in this update; I will address those as soon as I can. In other news, I have changed jobs. Previously, I worked full-time as a broadcast engineer/IT person for WGCR Radio. I still work part-time for them, amongst other radio stations, but my full-time position is now as Director of Information Technology for Pisgah Astronomical Research Institute (PARI), a radio/optical astronomical observatory located in Western North Carolina. You can find out more about PARI at our website, www.pari.edu. PARI is already using PostgreSQL for several applications, and soon will be looking at PostgreSQL for a large data warehousing application. And, in this case, I do mean large. I will be indexing and storing over three million astronomical photographic plates (if plans come together!), where each plate will scan in at roughly 650-750MB in size (uncompressed) (and this is 8-level grayscale scanning). Mass storage will be critical of this priceless data store, and PostgreSQL may very well fit the bill. I'm still in the planning phases, and we are still trying to secure funding for this project. But I am relatively confident that PostgreSQL will rise to the occassion. Some of the plates in question are over 100 years old. New challenges, new opportunities. But still the same PostgreSQL. -- Lamar Owen Director of Information Technology Pisgah Astronomical Research Institute ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.4 Beta RPMS?
On Sunday 13 July 2003 18:09, Matthew T. O'Connor wrote: > I know it's early, but I was just wondering if there would be 7.4 rpms > during beta? I plan to have them. I'm on vacation this week, so it will be next at earliest, depending upon when the beta itself is ready. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] help with rpm script
On Wednesday 02 July 2003 01:20, Craig Jensen wrote: > I need to have the rpm when installed create a database and a user with > privilege to that database. These are the command functions I need to > execute within the rpm... > # service postgresql start > # su postgres > # createdb account > # psql account < my1.sql > # psql account < my2.sql > # exit It is an extremely bad idea to do this. Scriptlets in RPM run in a weird mode. Rather, in your spec file, do an initdb in the %install phase, and run a restore of the precreated database (in %install, again, but this might be a little tricky to do, since the postmaster as associated executables are in the buildroot, not in a really runnable position). Then have this packaged as, say, postgresql-data or somesuch. Add the precreated dump (if it's a dumpall, it will have the database name and all users as part of the dump). Or have the initscript in /etc/rc.d/init.d perform the restore immediately after the initdb that the first initscript run will do. But you really don't want to be doing this in %post. What if it's an upgrade? RPM upgrades and installs are identical from the scriptlet's point of view (except for the one parameter). I have a little experience in this regard, having maintained the mainline PostgreSQL RPM's for four years. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
On Monday 23 June 2003 15:42, Dann Corbit wrote: > Let me rephrase it: > "Only a cohesive, organized testing effort can result in a product that > is proven reliable." One can never 100% prove reliability without time in the field with real-world data, testing or no testing. I would dare say that there are numerous reliable software packages out there in OSS-land that have never had that sort of testing. But it really hinges on ones definition of proof, no? Furthermore, the beta testers here in hackers are not 'end-users' per se. The people in hackers who test the betas are very valuable as our QA team. PostgreSQL is already proven reliable, to various degrees of reliability, enough to where a PostgreSQL backend was approved as the new .ORG registry. The track record continues, without mathematically rigorous and cohesive testing. Such testing would be useful, of course, by it is not required for our purposes. Those who want rigorous testing can do the rigorous testing. You yourself said that your company has a separate QA team from the development team; OK, organize a rigorous QA team. While you won't stop releases (unless you find showstopper bugs, like those that have been found by our wonderful hackers testers), your input into actually testing PostgreSQL (as opposed to trying to convince someone else to test for you) would be valuable. But you're not going to get me to do it; I do enough testing of a varied nature already. I do this for fun. If you find testing fun, more power to you. :-) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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
Re: [HACKERS] Pre-allocation of shared memory ...
On Saturday 14 June 2003 16:38, Andrew Dunstan wrote: > IOW, simply the presence of /proc/sys/vm/overcommit_memory with a value set > to 0 doesn't guarantee you won't get an OOM kill, AFAICS. Right. You need the value to be 2 or 3. Which means you need Alan's patch to do that. > I *know* the latest RH kernel docs *say* they have paranoid mode that > supposedly guarantees against OOM - it was me that pointed that out > originally :-). I just checked on the latest sources (today it's RH8, > kernel 2.4.20-18.8) to be doubly sure, and can't see the patches. (That > would be really bad of RH, btw, if I'm correct - saying in your docs you > support something that you don't) But note these two lines in the docs with 2.4.20-13.9 (RHL9 errata): * This describes the overcommit management facility in the latest kernel tree (FIXME: actually it also describes the stuff that isnt yet done) Pay double attention to the line that says FIXME. IOW, they've documented stuff that might not be done! You can try Red Hat's enterprise kernel, but you'll have to build it from source. RHEL AS is available online as source RPMs. Also understand that the official Red Hat kernel is very close to an Alan Cox kernel. Also, if you really want to get down and dirty testing the kernel, a test suite is available to help with that, known as Cerberus. Configs are available specifically tuned to stress-test kernels. I think Cerberus is on Source Forge. So, make sure you have a kernel that allows overcommit-accounting mode 2 to prevent kills on OOM. Theoretically mode 2 will prevent the possiblity of OOM completely. If I read things right, if you have double swap space mode 0 will not OOM nearly as quickly. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Pre-allocation of shared memory ...
On Friday 13 June 2003 15:29, Lamar Owen wrote: > It is or was a Linux kernel problem. The 2.2 kernel required double swap > space, even though it wasn't well documented. Early 2.4 kernels also > required double swap space, and it was better documented. Current Red Hat > 2.4 kernels, I'm not sure which VM system is in use. The old VM certainly > DID require double physical memory swap space. After consulting with some kernel gurus, you can upgrade to a straight Alan Cox (-ac) kernel and turn off overcommits to cause it to fail the allocation instead of blowing processes out at random when the overcommit bites. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Pre-allocation of shared memory ...
On Friday 13 June 2003 12:46, Nigel J. Andrews wrote: > On Fri, 13 Jun 2003, Lamar Owen wrote: > > Incidentally, Red Hat as of about 7.0 began insisting on swap space at > > least as large as twice RAM size. In my case on my 512MB RAM notebook, > > that meant it wanted 1GB swap. If you upgrade your RAM you could get > > into trouble. In that case, you create a swap file on one of your other > > partitions that the kernel can use. > I'm not sure I agree with this. To a large extent these days of cheap > memory swap space is there to give you time to notice the excessive use of > it and repair the system, since you'd normally be running everything in > RAM. It is or was a Linux kernel problem. The 2.2 kernel required double swap space, even though it wasn't well documented. Early 2.4 kernels also required double swap space, and it was better documented. Current Red Hat 2.4 kernels, I'm not sure which VM system is in use. The old VM certainly DID require double physical memory swap space. >From a message I wrote in January of 2002: "On Tuesday 22 January 2002 03:48 pm, Jim Wilcoxson wrote: > I should have said, we're running this way on 2.2.19, not 2.4 -J > > Is this Linux requirement documented anywhere? We're running 256MB > > of swap on 1GB machines and have not had any problems. But we don't > > swap much either. 2.2 actually needs 2x swap, but the problems are worse with 2.4. 2.2 won't die a horrible screaming death -- but 2.4 WILL DIE if you run out of swap in the wrong way. As to documentation, I can't tell you how I found out about it, as I'm under NDA from that source. However, it is public information: see http://lwn.net/2001/0607/kernel.php3 for some pointers. Also see http://www.geocrawler.com/archives/3/84/2001/5/0/5867356/ http://www.tuxedo.org/~esr/writings/ultimate-linux-box/configuration.html and http://www.ultraviolet.org/mail-archives/linux-kernel.2001/28831.html And note that Red Hat Linux 7.1 and 7.2 will complain vociferously if you create a swap partition smaller than 2x RAM during installation (anaconda). What it doesn't do is complain when you upgrade RAM but don't upgrade your swap." Now, as to whether this is _still_ a requirement or not, I don't know. Search the lkml (Linux Kernel Mailing List) for it. However, understand that the Red Hat kernel is closer to an Alan Cox kernel than to a Linus kernel. At least that was true up to 2.4.18; the Red Hat 2.4.20 is very different, with NPTL and its ilk thrown in. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Pre-allocation of shared memory ...
On Friday 13 June 2003 11:55, Josh Berkus wrote: > Regrettably, few of the GUI installers for Linux (SuSE or Red Hat, for > example), include adequate swap space in their "suggested" disk formatting. > Some versions of some distributions do not create a swap partition at all; > others allocate only 130mb to this partition regardless of actual RAM. Incidentally, Red Hat as of about 7.0 began insisting on swap space at least as large as twice RAM size. In my case on my 512MB RAM notebook, that meant it wanted 1GB swap. If you upgrade your RAM you could get into trouble. In that case, you create a swap file on one of your other partitions that the kernel can use. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 9: most folks find a random_page_cost between 1 or 2 is ideal
Re: [HACKERS] Wrong version of jdbc in 7.3.3 rpms
On Thursday 05 June 2003 11:39, Barry Lind wrote: > Does anyone know why apparently the 7.3beta1 version of the jdbc drivers > are what is included in the 7.3.3 rpms? > > The pg73b1jdbc3.jar file is very old (it is the 7.3 beta 1 version). > > What RPMs are you using? You should contact whoever produced those RPMs > > to get them built with the current version. The 'official' version is > > the source code that is tagged with the 7.3.3 freeze label (which is the > > version that is currently posted on the jdbc.postgresql.org web site) I am whoever. :-) I have not synced up with the version on jdbc.postgresql.org (primarily because I didn't know about there being a newer version). I do not have a JDK installed here, so I don't build the JDBC driver from source. So, I'll blame my own bit rot. Since the postgresql-jdbc RPM has no dependencies and is a distribution-independent RPM, I'll roll a new one. This won't require a rebuild on all the distributions supported, since we're talking distribution independent jars. However, I wouldn't mind pulling the JDBC subpackage out of the main set entirely, and having a separate RPM distribution for that. You could maintain that yourself easily enough. I can even give you a starting spec file, and the JDBC driver could have a separate release schedule, which might be appropriate anyway. Going the one obvious next step forward, is there a compelling reason to include the JDBC client as part of the main tarball, rather than a separate project (ODBC is separate, as is the C++ and Perl clients) (and the same thing can be said for the Python client)? Does the JDBC client need backend source code, or is it happy being built with just the necessary fe protocol headers? (I'm thinking out loud here -- I can see a reason for the JDBC driver to have a separate release schedule from the main tarball, but I'm not saying 'JDBC is a problem child! Let's yank it because I don't want to deal with it!'). Barry, what would be your preference? What would best serve JDBC users? (other than me installing all the software necessary to build the JDBC from source -- this requires non-vanilla software in the form of the JDK, as well as the build environment that the makefiles want, and with me not being a Java developer at this time, I wouldn't necessarily be up on what is considered the 'canonical' development or runtime environments. With the other portions of PostgreSQL, nothing beyond the stock distribution is required for build.) I think it would best serve the users for an active JDBC developer to make that distribution. Please advise how you would like to handle this. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] No more RH7.3 RPMs?
On Thursday 29 May 2003 17:41, Sander Steffann wrote: > Someone else has already built RPMs for RH73 and Lamar has already uploaded > them to ftp.postgresql.org. I just completed the RH62 packages. Lamar will > put them on the FTP server, but until then they can be picked up from > http://www.steffann.nl/PostgreSQL/v7.3.3/ if somebody needs them quickly. Uploading now. Thanks, Sander, and Thanks, Timothy! -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] No more RH7.3 RPMs?
On Thursday 29 May 2003 07:26, ow wrote: > RH7.3 is a supported distribution for at least 6 months. By Red Hat, but not necessarily by us. That being said: > Any plans to add > Postgres 7.3.3 RPMs for RH7.3? Yes. Please understand that I only have at my disposal machines running Red Hat 9 (my personal notebook), Red Hat 8.0 (a couple of servers I admin), and Aurora 1.0 (0.42) (my personal SPARC servers). I do not have a RH7.3 box, so I can't directly support RH 7.3. Please also understand that I am not being paid by anyone at this time to do RPM releases -- it is a completely volunteer operation. That being said, I have volunteers who build RPMs for the older distributions. RH 7.3 RPMs should be available today, with RH 6.2 RPMs possibly also available today. Also please note that Red Hat doesn't support PostgreSQL 7.3.3 on Red Hat Linux 7.3. RHL 7.3 shipped with a different version of PostgreSQL, which is the only version that they will support on Red Hat Linux, unless Red Hat releases an errata through RHN for PostgreSQL. While I and Red Hat closely track on the contents of the RPMs, the RPMs labeled with 'PGDG' are not in any way being made available by Red Hat Software. They are being made available by the PostgreSQL Global Development Group. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] PostgreSQL RPM's and Red Hat.
I was asked a question about Red Hat's involvement in the PGDG RPM's by e-mail. Since at least one person was interested, I thought I would post to the list to satisfy everyone's curiosity. At the end of this e-mail is a Grand Unified Changelog for the RPMset. It is massive. Back in the summer of 1999, I was quite fed up with the snail's pace of updates for PostgreSQL in RPM form from Red Hat. I likewise was fed up (and still am!) with the way that PostgreSQL major version upgrades require unusual steps for completion. As a result, I volunteered to take on building and maintaining RPMs. I didn't know what I was getting into! Anyway, to make a long story short, I took the existing RPM's (for 6.5 beta) and worked them around into shape. Red Hat took notice, and my RPM's found their way into Red Hat Linux 6.1. I have striven to keep close sync ever since. How close (or not) of sync I have kept is illustrated by the changelog. This changelog is in somewhat reverse chronological order, newest entry first. I began pruning the changelog for each major release for 7.0. So what follows is the full (branched) changelog. Maybe this will be of some interest to someone. ++ 7.3.x branch: * Tue May 27 2003 Lamar Owen <[EMAIL PROTECTED]> 7.3.3-1PGDG - Synced up with RawHide. - 7.3.3 - Eliminate spurious symlink of libpq.so.2. - Dropped isblank patch; 7.3.3 uses pg_isblank * Wed Apr 16 2003 Andrew Overholt <[EMAIL PROTECTED]> 7.3.2-4 - Obsolete postgresql-perl and postgresql-tk * Mon Feb 17 2003 Elliot Lee <[EMAIL PROTECTED]> 7.3.2-4 - Add ppc64 patch * Fri Feb 14 2003 Andrew Overholt <[EMAIL PROTECTED]> 7.3.2-3 - Remove pltcl.so from postgresql-tcl and plpython.so from postgresql-server. * Wed Feb 12 2003 Andrew Overholt <[EMAIL PROTECTED]> 7.3.2-2 - Fix typo in pg_hba.conf tighten patch. * Wed Feb 5 2003 Andrew Overholt <[EMAIL PROTECTED]> 7.3.2-1 - Initial 7.3.2 build. - Add bison and flex to BuildRequires line. * Mon Feb 03 2003 Lamar Owen <[EMAIL PROTECTED]> - 7.3.2-1PGDG * Wed Jan 22 2003 Tim Powers <[EMAIL PROTECTED]> - rebuilt * Thu Jan 09 2003 Elliot Lee <[EMAIL PROTECTED]> 7.3.1-5 - Rebuild for newer libssl - Add patch4 (isblank.patch) to make it all build * Sat Jan 4 2003 Jeff Johnson <[EMAIL PROTECTED]> 7.3.1-4 - use internal dep generator. * Fri Jan 3 2003 Andrew Overholt <[EMAIL PROTECTED]> 7.3.1-3 - Remove spurious PreReq line * Fri Jan 3 2003 Andrew Overholt <[EMAIL PROTECTED]> 7.3.1-2 - Rebuild with new 7.3.1 tarball - Remove obsoletes postgresql-perl line (should have been postgresql-plperl) as we did not have that package previously * Mon Dec 23 2002 Lamar Owen <[EMAIL PROTECTED]> - 7.3.1-1PGDG - Fix dependency order for test and pl subpackages. - Fixed a bug in the initscript for echo_success * Wed Dec 18 2002 Andrew Overholt <[EMAIL PROTECTED]> 7.3.1-1 - Initial 7.3.1 build. * Tue Dec 17 2002 Nalin Dahyabhai <[EMAIL PROTECTED]> 7.3-6 - Make postgresql-pl obsolete postgresql-perl, not postgresql-plperl * Fri Dec 13 2002 Andrew Overholt <[EMAIL PROTECTED]> - Remove perl(Pg) dependency - Bash profile PGDATA fix - Updated initscript to new community version * Tue Dec 10 2002 Andrew Overholt <[EMAIL PROTECTED]> - Upgrade to 7.3 community spec file. - Add patch to use with multilib. - Change explicit path names to use RPM macros (multilib). - Add security patch. * Thu Dec 05 2002 Lamar Owen <[EMAIL PROTECTED]> - 7.3-2PGDG - Fix typo in initscript. Argh!! * Wed Dec 04 2002 Lamar Owen <[EMAIL PROTECTED]> - 7.3-0.5PGDG - Jerk out all perl client stuff and kludgage - Rename plperl subpackage to a pl subpackage containing all but PL/Pgsql PL's - Eliminate locale and multibyte explicit enables -- they are both defaults now - Eliminate pgaccess code; it's not a part of the main tarball anymore - Eliminate ODBC stuff -- it's also separate now. Use unixODBC instead. - Eliminated separate tk client package -- rolled the tk client into the tcl client. - Moved pltcl into the pl subpackage. - Added plpython to the pl subpackage. - /etc/sysconfig/pgsql is sysconfdir for multiple postmaster startup. * Mon Dec 02 2002 Lamar Owen <[EMAIL PROTECTED]> - 7.3-0.1PGDG (not released) - Integrate 7.3 jar's courtesy Joe Conway - Integrate multi-postmaster initscript courtesy Karl DeBisschop - Some renames and restructures. - Stripped out the last dregs of the postgresql-dump migration script. - Conflicts with less than 7.3. 7.2.x branch (breaks chronology due to parallel releases) * Mon Apr 14 2003 Lamar Owen <[EMAIL PROTECTED]> - 7.2.4-2PGDG - Patch for Red Hat Linux 9 compile. - Fixed some missing files in devel, python, odbc, tcl, and contrib packages. * Fri Jan 31 2003 Lamar Owen <[EMAIL PROTECTED]> - 7.2.4-1PGDG * Wed Oct 02 2002 Lamar
Re: [PERFORM] [HACKERS] OSS database needed for testing
On Friday 04 April 2003 14:54, Merlin Moncure wrote: > I can tell you, though; the land mobile database is much more > complicated. Getting it to run decently on pc hardware is a significant > engineering challenge. Then it sounds like it's a better fit for Josh's requirements. > ill-fated DTV rollout and the failed AM stereo. It's a conservative > industry. Tell me about it. Yet we get IBOCand the 30,000 translator apps in the one week window... Anyway, those topics more correctly belong to [EMAIL PROTECTED]; rather off-topic here. I do still want to get CDBS in a PostgreSQL setup, with automatic nightly import, at some point in time. Just probably not as quickly as Josh needs a dataset to crank on. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [PERFORM] [HACKERS] OSS database needed for testing
On Friday 04 April 2003 14:23, Merlin Moncure wrote: > Up until about 6 months ago, I worked at a company called RadioSoft. > They are a provider of high quality database, engineering, and GIS > software. The company has its roots as source of engineering tools for > broadcast engineers. They currently offer several products and services > (including online web based database services), some of which are based > on postgres, some not. You might consider checking them out. I'm quite familiar with RadioSoft. Can't afford any of the software; familiar with the products... :-) I've been putting together open source tools to do much of the same stuff. With the release of the FCC's Fortran source, I've been able to do virtually everything I need to do. But while the LMR dataset is larger, the MB dataset is just as varied. I'm interested in both, however. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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: [PERFORM] [HACKERS] OSS database needed for testing
On Friday 04 April 2003 11:47, Merlin Moncure wrote: > The location of the data of interest is at > /pub/Bureaus/Wireless/Databases/uls/. > wireless services. This includes most two way systems and point to > multipoint (microwave) but not broadcast (AM, FM, TV) and not advanced > radio. Also check out the cdbs files (which contain the broadcast stuff as well as more) at /pub/Bureaus/Mass_Media/Databases/cdbs/ (which I would be more interested in doing, since I am a broadcast engineer by profession....) -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib and licensing
On Thursday 03 April 2003 09:29, Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > >>> And its stubs are in the backend, of all places. > >> Really? I must have missed that. > > On Linux as compiled in Red Hat 9, at least: > > [EMAIL PROTECTED] lowen]$ ldd /usr/bin/postgres > > libreadline.so.4 => /usr/lib/libreadline.so.4 (0x401c6000) > That's because our build mechanism links *all* needed libraries in *all* > executables, rather than trying to distinguish which ones are actually > used by each executable. The ldd indication is the only connection to > libreadline --- if it had been a statically-linked situation, you'd find > no trace of readline (nor several other of these libraries, I suspect) > in the backend executable. As I said, its 'stub' is there. But it is in (and used by) psql (as of 7.3.2). -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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: [HACKERS] contrib and licensing
On Thursday 03 April 2003 00:04, Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > And its stubs are in the backend, of all places. > Really? I must have missed that. On Linux as compiled in Red Hat 9, at least: [EMAIL PROTECTED] lowen]$ ldd /usr/bin/postgres libpam.so.0 => /lib/libpam.so.0 (0x4002c000) libssl.so.4 => /lib/libssl.so.4 (0x40034000) libcrypto.so.4 => /lib/libcrypto.so.4 (0x40069000) libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x4015a000) libz.so.1 => /usr/lib/libz.so.1 (0x401b8000) libreadline.so.4 => /usr/lib/libreadline.so.4 (0x401c6000) libtermcap.so.2 => /lib/libtermcap.so.2 (0x401f3000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x401f7000) libresolv.so.2 => /lib/libresolv.so.2 (0x40224000) libnsl.so.1 => /lib/libnsl.so.1 (0x40236000) libdl.so.2 => /lib/libdl.so.2 (0x4024b000) libm.so.6 => /lib/tls/libm.so.6 (0x4024e000) libc.so.6 => /lib/tls/libc.so.6 (0x4200) libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x40271000) libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 (0x40273000) libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x40286000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x4000) [EMAIL PROTECTED] lowen]$ /usr/bin/postgres --version postgres (PostgreSQL) 7.3.2 [EMAIL PROTECTED] lowen]$ > Certainly, any of this stuff *could* be reimplemented. But for stuff > that's being proposed for contrib, what's theoretically possible given > enough demand isn't the important real-world issue. Contrib stuff is, > by definition, stuff that hasn't yet had all that much work put into it. > So it's appropriate to ask where it can really run *right now*. FWIW, very few things in contrib use anything beyond libc. The dblink stuff is a notable exception. It needs an SSL and a Kerberos 5 library. If the library is reasonably popular (meaning it's in at least one major OS distribution, including Debian) then 'what's the harm?' If the lib isn't that popular, then, regardless of license the question 'should something that uses it even be here' should be asked. The issue of a straight GPL library is serious for us; a LGPL one less so. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib and licensing
On Wednesday 02 April 2003 21:59, Stephan Szabo wrote: > On Wed, 2 Apr 2003, Lamar Owen wrote: > > > "However, linking a "work that uses the Library" with the Library > > > creates an executable that is a derivative of the Library (because it > > > contains portions of the Library), rather than a "work that uses the > > > library". The executable is therefore covered by this License. > > > Section 6 states terms for distribution of such executables." > > Everyone does realize that on Linux PostgreSQL binaries link against > > glibc, which is LGPL.. > I assume the standard dynamic linker counts as "a suitable shared library > mechanism for linking with the Library" as per LGPL 6b. ;) Then I guess we had better not make any static linked builds, no? The whole thread just got ridiculous, that's all. So I attempted to illuminate the 'ridiculosity' of the whole matter. Speaking of 'ridiculous' reminds me: Readline is full-bore GPL. There's no 6b exception there. We dynamically link readline, on most Linux distributions. Of course, Tom has a point; there are alternatives available. None are as good as readline, though. Which is one of the reasons it's GPL'd in the first place, according the the GPL FAQ. In fact, the GPL FAQ contains this little tidbit: 'If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL? Yes, because the program as it is actually run includes the library.' :-O Hmmm. 'as it is actually run' means with the library embedded in the resulting dynamically linked program -- just because it's dynamically linked doesn't mean that code isn't part of the program. Should we say 'bye bye' to readline? Of course, there's the issue of the BSD license being 'compatible' with the GPL. Then it gets hairy. And picky. Fun fun fun. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] contrib and licensing
On Wednesday 02 April 2003 22:39, Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > > > Everyone does realize that on Linux PostgreSQL binaries link against > > glibc, which is LGPL.. > And your point is? That everyone is being entirely too picky. Hey, we link against other things, too. Some aren't LGPL. The readline example is a good one, incidentally: it's GPL. And its stubs are in the backend, of all places. At least on Linux. Gotta watch any 'static builds' then. > On other Unixoid systems you can link against BSD-license libc code, or > some-random-proprietary-license code from HP or Sun or whomever. glibc > doesn't have a monopoly in that sphere. But mlw is offering code that > will *only* run against a single implementation that is LGPL licensed. > That makes it effectively LGPL. One could clean-room reimplement if the demand is enough. But, if one wants to get picky, let's talk about the license issue of PL/Python. The PSF looks like a rat's nest. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib and licensing
On Wednesday 02 April 2003 18:11, Dann Corbit wrote: [snip] > > True. But not linking to LGPLd libs would be a bit extreme there. > I disagree. Because of the language in the LGPL: > http://www.gnu.org/copyleft/lesser.txt > > I would not use LGPL tools in any finished commercial project. For me, > if PostgreSQL linked against LGPL libraries, it would kill its > usefulness for me completely. > "However, linking a "work that uses the Library" with the Library > creates an executable that is a derivative of the Library (because it > contains portions of the Library), rather than a "work that uses the > library". The executable is therefore covered by this License. > Section 6 states terms for distribution of such executables." Everyone does realize that on Linux PostgreSQL binaries link against glibc, which is LGPL.. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Numbering of the next release: 8.0 vs 7.4
On Wednesday 12 March 2003 09:55, Robert Treat wrote: > Personally I think Justin is a little off base with his criteria, since > I see the FE/BE protocol changes as the real differentiator between an > 8.0 and 7.4. Everyone is effected by a FE/BE protocol change, not nearly > so many are effected by either win32 or PITR. And think of this crazy > scenario: We release an 8.0 with PITR, then need either a 8.1 or a 9.0 > with a FE/BE overhaul, then need a possible 10.0 because we've added > win32... yuk. FWIW, the 6.4 protocol change didn't force a move from 6.3.2 to 7.0. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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: [HACKERS] location of the configuration files
On Sunday 16 February 2003 13:15, Tom Lane wrote: > Sure. I'm happy to change the software in a way that *allows* moving the > config files elsewhere. So we agree. Perfect. > But it's not apparent to me why you insist on > forcing people who are perfectly happy with their existing configuration > arrangements to change them. Me? Trying to force things to change? You misunderstand me. No, I'm trying to understand the rationale for a (relative to the way other designed-multiple daemons do things) different, non-standard configuration process. I understand better now; the exercise was a success. Many thanks. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] location of the configuration files
On Sunday 16 February 2003 00:16, Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > Would you mind elucidating which point of view is yours? > Primarily, one that wants to have multiple postmasters running, of the > same or different versions; including test and temporary installations > that mustn't conflict with the existing primary installation on a machine. Well, due to our upgrading difficulty, having multiple versions running has its advantages. > You're talking about making manual installations significantly more > difficult (and error-prone, I think) in order to simplify automated > installs. Now you've acknowledged that your script can do what > you want it to, and in fact already does. Why is it good to make my > life more difficult to make a script's easier? Cycles are cheap. > I like to think that my time is worth something. The script's been out there for awhile. It does some things well, and some things not so well. The config files are still coresident with the database, and backup is more difficult than it can be. Meeting all these needs (with configure switches, configuration file directives, etc) would be a good thing. And that's what I'm after; maximum usability for the maximum audience. I believe pretty strongly that the usage to which you or I would put PostgreSQL is probably quite different from the average user's way of using PostgreSQL. Most probably the typical user has a single installation with multiple databases with little need to run isolated postmasters. > Nor will I buy an argument that only a few developers have need for test > installations. Ordinary users will want to do that anytime they are > doing preliminary tests on a new PG version before migrating their > production database to it. To the extent that you make manual selection > of a nonstandard datadir location more difficult and error-prone, you > are hurting them too. While I'm not going to speak for all users, I know that I don't put a development database system on my production servers. The production machine only runs production servers, period. Hardware is cheap. I have development machines for development databases. One also has the error-prone PATH issues with multiple versions, which, if you are running a typical RPM installation becomes quite difficult to manage, since the RPM version's executables are in /usr/bin. This could be changed; I've thought about changing it. But I'm not sure of the best way to make multiple versions peacefully and seamlessly coexist -- particularly when older versions may not even build on the newer OS: but we've been over that discussion. Care for a poll? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] location of the configuration files
On Saturday 15 February 2003 21:06, Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > Shouldn't we be consistent and have initdb use the datadir set in the > > config file, which could be supplied by a ./configure switch? > That'd mean there is no way to perform an initdb into a nonstandard > location without first hand-preparing a config file. I don't much care > for that. Six of one and half-dozen of another. And that's my real point. We do things quite differently from many other standard services, even those which are built from the ground up for multiple instances. Making things more consistent for admins, even if it's not what we are used to or what we might like (because it's familiar) should at least be thought about. I'm not advocating changing just for the sake of change; but getting a new fresh look at our current setup can't hurt. > > I'm looking at a packager point of view here. The initdb is done well > > after the package is made, and installed. It would be ideal from this > > point of view to have things fully configured pre-initdb (and thus > > pre-packaging). > This point of view means that no post-configure knowledge can be > applied. We might as well forget the separate initdb step altogether > and have "make install" do it. I wouldn't complain. Although that isn't conducive to the multiple instance case. The necessary post-configure knowledge would be in the instance postgresql.conf file. One place for it. But this is hypothetical; fishing around the waters here at this point. Realize that my own packages apply an initdb automatically if an install isn't found the first time the system initscript is started. It is virtually automatic. With the multiple postmaster support, creating a couple of files and a symlink (for the initscript), and starting the new initscript symlink does all the dirty work. But it could be easier. > I realize that from a packager's point of view, the separate initdb step > is not very useful. But it is from my point of view. Would you mind elucidating which point of view is yours? General idea of who else might have the same point of view, and why you find the initdb in its current form to be more useful than alternatives. Again, I'm fishing for knowledge -- if nothing else it gives me an answer to those users who send me nastygrams about the way things are right now. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] location of the configuration files
On Saturday 15 February 2003 20:19, Tom Lane wrote: > Lamar Owen <[EMAIL PROTECTED]> writes: > > Just exactly why does initdb need to drop any config files anywhere? > Because we'd like it to edit the correct datadir into the config file, > to take just the most obvious example. Shouldn't we be consistent and have initdb use the datadir set in the config file, which could be supplied by a ./configure switch? > There has also been a great deal > of discussion recently about other things initdb might automatically put > into the config file after looking at the system environment. That's > not happened yet, but we'd really be restricting ourselves to say that > initdb can never customize the config files. Customize != writing the original. I'm looking at a packager point of view here. The initdb is done well after the package is made, and installed. It would be ideal from this point of view to have things fully configured pre-initdb (and thus pre-packaging). But I understand that this might not be ideal from a multipostmaster point of view. Surely these two can be reconciled. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(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: [HACKERS] location of the configuration files
On Friday 14 February 2003 11:02, "Shridhar Daithankar wrote: > Especially the whole discussion of PGDATA stuff fails to register as > significant IMO. Right now, I can do things the way I want to do and I > guess it is pretty much same with everyone else. Is it last topic left to > improve? If it weren't significant to a few, then there wouldn't be the traffic. If there's too much traffic, well, there are alternatives. > Keep it simple and on tpoic guys. This is hackers. Keep it low volume > otherwise, two years down the lines, archives will be unsearchable.. The system configuration of PostgreSQL is on topic for -hackers. IMNSHO. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] location of the configuration files
On Friday 14 February 2003 15:10, Tom Lane wrote: > I don't see why we don't just let initdb install suggested config files > into the new $PGDATA directory, same as it ever did. Ok, let me take another tack. Just exactly why does initdb need to drop any config files anywhere? We provide templates; initdb can initialize the data structure. If we can by default (as part of make install) put the config file templates in $SYSCONFDIR (as set by ./configure), then why does initdb need to retouch them? I say that having configured PostgreSQL like this: (this is for 7.2.4, not 7.3.x) --enable-locale --with-CXX --prefix=/usr --disable-rpath --with-perl --enable-multibyte --with-tcl --with-odbc --enable-syslog --with-python --with-openssl --with-pam --with-krb5=/usr/kerberos --enable-nls --sysconfdir=/etc/pgsql --mandir=/usr/share/man --docdir=/usr/share/doc --includedir=/usr/include --datadir=/usr/share/pgsql So, in my case, it would be preferable to me for initdb to not make a default postgresql.conf, pg_hba.conf, and pg_ident.conf. The make install process should populate sysconfdir (/etc/pgsql here) with those files. Why does initdb even need to be involved now (I know the historical reason)? Comments? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] location of the configuration files
On Thursday 13 February 2003 21:49, Tom Lane wrote: > Oliver Elphick <[EMAIL PROTECTED]> writes: > > need is verified, I could do this by moving the pid file from > > $PGDATA/postmaster.pid to /var/run/postgresql/5432.pid and similarly for > > other ports. This would also have the benefit of being more FHS > > compliant What do people think about that? > No chance at all. Breaking the connection between the data directory > and the postmaster.pid file means we don't have an interlock against > starting two postmasters in the same data directory. It's not a pid file in the /var/run sense, really. It's an interlock for PGDATA. So it might be argued that postmaster.pid is misnamed. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] location of the configuration files
On Thursday 13 February 2003 21:13, Bruce Momjian wrote: > Lamar Owen wrote: > > It isn't without precedent to have a directory under /var/run. Maybe > > /var/run/postgresql. Under this one could have a uniquely named pid > > file. > But how do you handle the default then, where you have postmaster.pid in > /data? Do we rename it to postmaster.pid.5432 so it can sit in > /var/run/postgresql alone with other backends? Well, you can have the default as 'postmaster.pid' if it wasn't named. But more thought is needed. I'll have to admit; the wisdom of AOLserver having a full-fledged tcl config script is beginning to look better and better. > Another issue is that pg_ctl looks at that file, so moving it around is > going to be tricky. pg_ctl could be interesting. > I am now wondering if we even want pg_hba_dir and pg_ident_dir. Seems > we can assume they are in the same directory as postgresql.conf. That > leaves only data_dir as new for postgresql.conf. Ok, if we're going this far already, tell me exactly why we have three config files. Why not really Unify things and fulfil the full promise of Grand Unified Configuration by rolling hba and ident into postgresql.conf. Is there a compelling reason not to do so? The structure of that configuration data would have to change, for sure. Although I seem to remember this being suggested once before, but my mind draws a blank trying to recall it. Just a suggestion; maybe not even a good one, but something that crossed my mind. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] location of the configuration files
On Thursday 13 February 2003 20:09, Bruce Momjian wrote: > Lamar Owen wrote: > > This isn't the same environment, Bruce, that you got into back when it > > was still Postgres95. > So you are saying this isn't my grandma's database anymore. :-) I actually thought of saying it that way, too. :-) > Anyway, I think I have _a_ proposal that we can use to work toward a > goal. > First, a few conclusions: > We can't use /var/run because we need the postmaster to create > those, and it isn't root. It isn't without precedent to have a directory under /var/run. Maybe /var/run/postgresql. Under this one could have a uniquely named pid file. I say uniquely named so that multiple postmasters could run. Naming those files could be fun. /var/run/postgresql would be owned by the postmaster run user. This of course requires root to install -- but would be completely optional. > pg_dumpall > foo && rm -rf $PGDATA && initdb > discards all the config files. Yes, this is a big deal. It makes it more difficult to properly restore. While it's not impossible to do so now, of course, it just could be a little easier. > So, I propose we change a few things. > OK, first, we keep postmaster.pid and postmaster.opts in /data. We > can't put them in /var/run, and /data seems like the best spot for them. Can we make that configurable? The default in pgdata is fine; just having the option is good. > That leaves postgresql.conf, pg_hba.conf, and pg_ident.conf. I > recommend moving them all, by default, into pgsql/etc. I recommend we > add these to postgresql.conf: > data_dir = ../data > pg_hba_dir = ./ > pg_ident_dir = ./ > Those paths are relative to postgresql.conf. And these are all just defaults, easily changed. Good. > We then add a PGCONFIG variable and postmaster -C flag to point to the > config _directory_. That way, if folks want to move all of this into > /etc, then easily do that. This also pulls those files out of /data so > they are easier to back up. Yes. I'm thinking along the lines of this sort of structure: /etc |---postgresql |- name of postmaster one (unique ID of some kind) |- name of postmaster two . . Not difficult. > We can also firm up stuff in 7.5 by removing PGDATA and -D, and perhaps > removing the other duplicate postmaster flags that have postgresql.conf > entries. Now I really _like_ this idea. By removing it to 7.5, and therefore deprecating it in 7.4, this brings best practice into effect. However, at the same time, I wouldn't be opposed to leaving them in place, either, for backwards compatibility. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] location of the configuration files
On Thursday 13 February 2003 18:41, Vince Vielhaber wrote: > On Thu, 13 Feb 2003, Lamar Owen wrote: > > PostgreSQL is as critical as PHP, Apache, or whatever other package is > > being backended by PostgreSQL. If the package is provided by the > > distributor, consider it part of the OS. If it isn't, well, it isn't. > You completely miss my point, but lately you've been real good at that. No, Vince, I understand your point. But understand mine: it does matter who installed it. > Note, I'm not even including an MTA here. I said BASIC OPERATION. > If a package is not critical as I just outlined, it shouldn't matter who > installed it. 'Critical' is in the eye of the admin of the system in question. For my servers, if, for instance, sshd doesn't come up, then there's a major problem, as they are all headless. If the webserver doesn't come up, I have other problems, as OpenACS is mission-critical here. So what's critical is a question for the individual sysadmin. So, to continue your point, what is 'critical' to the 'basic operation' of the system shouldn't pollute /etc. So, let's eliminate the /etc/mail, /etc/samba, /etc/xinetd.d, /etc/X11, /etc/httpd, and the other subtrees foung in at least Red Hat 8. While we're at it, many other files in /etc need to go: named.conf for one. It depends on what you consider 'critical'. PostgreSQL is at least as critical on my systems as some of the other things that already 'pollute' /etc. > After the last go around with you Lamar, this will be my last response > to you on this. Aw Vince, I don't know what your problem is with conflicting opinions. But that's your choice. And Open Source is about _choice_. You are free to admin your systems your way, and I'm free to do so my way. And all's well. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] location of the configuration files
On Thursday 13 February 2003 18:07, Vince Vielhaber wrote: > Actually FHS says the opposite. If the distribution installs PostgreSQL > then the config files belong in /etc/postgresql. If the admin does then > they belong in /usr/local/etc/postgresql. FHS is out of their tree. If > PostgreSQL or any other package is not critical to the basic operation of > the operating system, it's config files shouldn't be polluting /etc. PostgreSQL is as critical as PHP, Apache, or whatever other package is being backended by PostgreSQL. If the package is provided by the distributor, consider it part of the OS. If it isn't, well, it isn't. This is so that local admin installed (from source -- not from binary package) files don't get clobbered by the next operating system binary upgrade. In that context the FHS (LSB) mandate makes lots of sense. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] location of the configuration files
On Thursday 13 February 2003 17:53, Bruce Momjian wrote: > Oliver Elphick wrote: > > What your comments strongly suggest to me is that projects like > > PostgreSQL and pine, along with everything else, should comply with FHS; > > then there will be no confusion because everyone will be following the > > smae standards. Messes arise when people ignore standards; we have all > > seen the dreadful examples of MySQL and the Beast, haven't we? > Can the FHS handle installing PostgreSQL as non-root? Once again, no one is trying to make an FHS install the default 'let's force everyone to think our way or no way' coercion. We just want the option. For those who wish to do non-root installs, nothing would need to change. You can still put it into /usr/local/pgsql (assuming you have permissions to put it there) or your home directory, or wherever. I deal with RPMs; Oliver deals with .deb's. Neither can be installed as non-root. The daemon can of course run as non-root (and it does, which is exactly correct); but the installation of the files is done as root _always_ in an RPM or deb environment. So I really don't care about non-root installs; sorry. I wonder what percentage of our users are not the administrator of the machine on which they are running PostgreSQL? I dispute the statement made earlier in the thread (not by Bruce) that PostgreSQL is by definition not an OS service. This is false, and needs to be realized by this community. PostgreSQL is becoming an essential OS core service in many cases: virtually all Linux distributions (the lion's share of our current distribution) include PostgreSQL as a core service. Many of our new users see PostgreSQL as 'SQL server' in the Red Hat installation menu. Now, on a Win32 server, what is PostgreSQL going to be considered? It is probably going to run as a service, right? So you need to be Administrator there to perform the install, right? This isn't the same environment, Bruce, that you got into back when it was still Postgres95. We are in the big leagues OS-wise, and we need to act like it. Assuming that we are a 'userspace' program (which is a misnomer anyway, as _anything_ non-kernel is 'userspace') is not going to cut it anymore. So we need to fit in to an OS environment, whether it is FreeBSD, OS/X, Win32, Solaris, or Linux. In FreeBSD, as the ports maintainer excellently posted, PostgreSQL should live in LOCALBASE. We should make that easy. In Win32, configuration might be better stored in the system registry (Argh! Did I actually say THAT! Yuck!) -- we should make even that easy. In OS/X we should use the OS/X paradigm (whatever that is). And we should make it easy to make PostgreSQL LSB-compliant for our very large Linux user community. We should be adaptable to the accepted administration paradigm on whatever system we are running -- this should be a minimum. These concerns vastly outweigh the occasional non-root install from source, in my mind at least. I am not opposed to that way even being the default; after all, leaving the default the same as now agrees with the principle of least surprise (although we really don't ascribe to that; witness the 7.2-7.3 migration fiasco -- 7.3 should have been 8.0 to warn people of the major changes going on in client connections). But I do advocate _allowing_ the configuration options Mark has enumerated -- although I really wish we could use the lowercase c instead, for consistency with other OS services. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] location of the configuration files
On Thursday 13 February 2003 10:03, Tom Lane wrote: > mlw <[EMAIL PROTECTED]> writes: > > Here is the test, configure a server, with sendmail, named, apache, and > > PostgreSQL. Tell me which of these systems doesn't configure right. > AFAIK, only one of those four is designed to support multiple instances > running on a single machine. This is not unrelated. One can run many nameds on a single machine by specifying '-c alternate_named.conf' , which then points to a different set of zone files, listens to either a different port or address, etc. I have personally done this, and it worked as if it were designed to do so. Apache can easily have multiple instances by passing the location of httpd.conf on the command line. Everything else comes from that. Although Apache's virtual hosting is typically use instead, it may be necessary for large sites to run multiple instances with degrees of separation at the config file level. I use AOLserver, which in version 3 is designed from the ground up for many (even thousands) of instances on a single box. You access this capability with the '-t' switch (it stands for 'tcl config script' -- previous versions of AOLserver had an 'ini' file accessed with '-i', and version 3 added the tcl config script and deprecated the ini file). In fact, since there is no default, you MUST use -t. The tcl config script specifies all the parameters that instance needs (with the exception of the user and group ID the server should run as, if started as root (for port 80 access) -- but that doesn't effect PostgreSQL since our port is above 1024). Two instances can even share a tcl config script, as long as the virtual server name is specified on the command line, and the tcl config has multiple virtual server sections. I personally only lightly use this feature, running a mere half dozen AOLserver's on one of my production servers. All of which share a single PostgreSQL instance; but that's a different story. AOLserver is an excellent example here, as everything that has a location is configurable. During ./configure, you can specify the prefix and the other standard autoconf type options. This includes the location of the --enable-thread built Tcl 8.4 that you have to have first. I have two versions of AOLserver on that machine, and they coexist very well, because I _can_ be so specific in where everything lies. I run OpenACS on two of those instances, and, due to the size of that install I have those two pageroots on a separate filesystem from the binaries and config script. It was just a single tcl config entry. No biggie. Even sendmail has a -c switch to specify the location of sendmail.cf: so, yes, you can run multiple instances, although it could be argued that it wasn't designed in. Next? -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
