Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
On Tue, 20 Mar 2001, Lamar Owen wrote: Ok, thanks to our snowstorm :-0 I have been working on the beta 6 RPM situation on my _slow_ notebook today (power outages for ten minutes at a time happening at hour or so intervals due to 45mph+ winds and a foot of snow). Well, I have preliminary RPM's built -- just need to work on the contrib tree situation. I ran regression the usual RPM way (which I am fully aware is not the normally approved method, but it _would_ be the method any RPM beta testers would use), and got a different failure, one that is not locale related (LC_ALL=C both for the initdb and the postmaster startup in the newest initscript). See attached regression.diffs for details of the temptest failure I experienced. Regression run with CWD=/usr/share/test/regress, user=postgres. ./pg_regress --schedule=parallel_schedule This is the only regression test failure I have found thus far. I have never seen this failure before, so I'm not sure where to proceed. Now to attack the contrib tree (looking forward to my new notebook, as this old P133 takes an hour and twenty minutes to slog through a full build). Seeing that RC1 is in prep, is there a pressing need to upload and release beta 6 RPM's, or will it be a day or two before RC1? Im going to do RC1 tonight ... so no pressng need :) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Beta 6 Regression results on Redat 7.0.
On Tue, 20 Mar 2001, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: I'm hoping it was a problem on my machine -- educate me on what caused the error Well, that's exactly what I'd like to know. The direct cause of the error is that DROP TABLE is finding that some other backend has a reference-count hold on a page of the temp table it's trying to drop. Since no other backend should be trying to touch this temp table, there's something pretty fishy here. Given that this is a parallel test, you may be looking at a low-probability timing-dependent failure. I'd say set up the machine and run repeat tests for an hour or three ... that's what I plan to do here. Okay, I roll'd an RC1 but haven't put it up for FTP yet ... I'll wait for a few hours to see if anyone can reproduce this, and, if not, put out what I've rolled ... say, 00:00AST ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Patch application
On Wed, 21 Mar 2001, Bruce Momjian wrote: I have created an FTP file containing all ourstanding patches. It is at: ftp://candle.pha.pa.us/pub/postgresql/patches.mbox I will keep this updated so people know their patches are in the queue and have not been forgotten. I may also use this to ask people for patch review. Can someone suggest a nice web frontend CGI script to a mbox file, one that shows sender/subject/date, etc? I don't need to search or modify the messages, just display them. would could make a read-only to public, write only to you, mailbox on mail.postgresql.org that ppl could access with IMAP ... ---(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] pgindent run?
On Wed, 21 Mar 2001, Bruce Momjian wrote: With RC1 nearing, when should I run pgindent? This is usually the time I do it. Does the silence mean I should pick a date to run this? Since I'm going to end up re-rolling RC1, do a run tonight on her, so that any problems that arise from pgindent this time can be caught with those testing RC1 ... ---(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] pgindent run?
On Wed, 21 Mar 2001, Bruce Momjian wrote:
OK, I am going to have dinner and then get started on the pgindent run.
I have also noticed we have some comments like:
/*
* one word
*
*/
that look funny in a few places. I propose:
/* one word */
to be consistent.
to be consistent with what ... ? isn't:
/* --
* comment
* --
*/
the standard?
With RC1 nearing, when should I run pgindent? This is usually the time
I do it.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RELEASE STOPPER? nonportable int64 constants inpg_crc.c
okay, this was the only one I was waiting to hear on ... the fix committed
this afternoon for the regression test, did/does it fix the problem? are
we safe on a proper RC1 now?
On Wed, 21 Mar 2001, Tom Lane wrote:
Zeugswetter Andreas SB [EMAIL PROTECTED] writes:
Recent changes in pg_crc.c (64 bit CRC) introduced non portable constants of the
form:
-c -o pg_crc.o pg_crc.c
287 | 0x, 0x42F0E1EBA9EA3693,
a..
a - 1506-207 (W) Integer constant 0x42F0E1EBA9EA3693 out of range.
Please observe that this is a warning, not an error. Your proposed
fix is considerably worse than the disease, because it will break on
compilers that do not recognize "LL" constants, to say nothing of
machines where L is correct and LL is some yet wider datatype.
I'm aware that some compilers will produce warnings about these
constants, but there should not be any that fail completely, since
(a) we won't be compiling this code unless we've proven that the
compiler supports a 64-bit-int datatype, and (b) the C standard
forbids a compiler from requiring width suffixes (cf. 6.4.4.1 in C99).
I don't think it's a good tradeoff to risk breaking some platforms in
order to suppress warnings from overly anal-retentive compilers.
regards, tom lane
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] BufferSync() FlushRelationBuffers() conflict
okay, baring you bein able to recreate the bug between now and, say,
13:00AST tomorrow, I'll wrap up RC1 and get her out the door ...
On Wed, 21 Mar 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Tom, since you appear to be able to recreate the bug, can you comment on
this, as to whether we are okay now?
Sorry for the delay --- I was down in Norfolk all day, and am just now
catching up on email. I will pull Vadim's update and run the test some
more. However, last night I only saw the failure once in about an
hour's worth of testing, so it's not that easy to reproduce anyway...
regards, tom lane
---(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
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] pgindent run?
On Wed, 21 Mar 2001, Bruce Momjian wrote: Bruce Momjian [EMAIL PROTECTED] writes: With RC1 nearing, when should I run pgindent? This is usually the time I do it. Does the silence mean I should pick a date to run this? If you're going to do it before the release, I think you should do it *before* we wrap RC1. I've said before and will say again that I think it's utter folly to run pgindent at the conclusion of the test cycle. I've been around this project for three major release cycles and we have seen errors introduced by pgindent in two of them. I don't trust pgindent to be bug-free and I don't believe you should either. OK, running now. Should I run it at another time or never? I'll put my vote on Tom's side of things ... run if after the release, right at the start of the next development cycle, so that any bugs that crop up aren't just as we are trying to release ... Hell, maybe once then and once *just* as we are going into first beta of a release ... Tom? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pgindent run?
On Wed, 21 Mar 2001, Bruce Momjian wrote: Bruce Momjian [EMAIL PROTECTED] writes: Hey, I am open to whatever people want to do. Just remember that we accumulate lots of patches/development during the slow time before development, and those patches become harder to apply. Peter E has some already. Why not start a devel cycle by (a) branching the tree, (b) applying all held-over patches, and then (c) running pgindent? If people can get their patches in all at one time, that would work. The only problem there is that people who supply patches against 7.1 will not match the 7.2 tree, and we get those patches from people for months. and those patches should only be applied to the v7.1 branch ... we are suggesting (or, at least, I am) is that you pgindent *HEAD* after we've branched off v7.1 ... ... that way, we go into the new dev cycle "clean", but we doon't mess up the *STABLE* tree ... ---(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] pgindent run?
On Wed, 21 Mar 2001, Bruce Momjian wrote: If people can get their patches in all at one time, that would work. The only problem there is that people who supply patches against 7.1 will not match the 7.2 tree, and we get those patches from people for months. and those patches should only be applied to the v7.1 branch ... we are suggesting (or, at least, I am) is that you pgindent *HEAD* after we've branched off v7.1 ... ... that way, we go into the new dev cycle "clean", but we doon't mess up the *STABLE* tree ... But we get patches from 7.0.X now that get applied to 7.1. All our developers are not working on CVS trees. Many use their main trees and send in the occasional patch. and most times, those have to be merged into the source tree due to extensive changes anyway ... maybe we should just get rid of the use of pgindent altogether? its not something that I've ever seen required on other projects I've worked on ... in general, most projects seem to require that a submit'd patch from an older release be at least tested on the newest CVS, and with nightly snapshots being created as it is, I really don't see why such a requirement is a bad thing ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] pgindent run?
On Wed, 21 Mar 2001, Bruce Momjian wrote: and most times, those have to be merged into the source tree due to extensive changes anyway ... maybe we should just get rid of the use of pgindent altogether? its not something that I've ever seen required on other projects I've worked on ... in general, most projects seem to require that a submit'd patch from an older release be at least tested on the newest CVS, and with nightly snapshots being created as it is, I really don't see why such a requirement is a bad thing ... In an ideal world, people would test on CVS but in reality, the patches are usually pretty small and if they fix the problem, we apply them. Seems like a lot of work just to avoid pgindent. If they are small, then why is pgindent required? And if they are large, is it too much to ask that the person submitting tests the patch to make sure its even applicable in the newest snapshot? ---(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] pgindent run?
On Thu, 22 Mar 2001, Bruce Momjian wrote: and most times, those have to be merged into the source tree due to extensive changes anyway ... maybe we should just get rid of the use of pgindent altogether? its not something that I've ever seen required on other projects I've worked on ... in general, most projects seem to require that a submit'd patch from an older release be at least tested on the newest CVS, and with nightly snapshots being created as it is, I really don't see why such a requirement is a bad thing ... In an ideal world, people would test on CVS but in reality, the patches are usually pretty small and if they fix the problem, we apply them. Seems like a lot of work just to avoid pgindent. If they are small, then why is pgindent required? And if they are large, is it too much to ask that the person submitting tests the patch to make sure its even applicable in the newest snapshot? The problem is that the small ones don't apply cleanly if they don't match the indenting in the source. but ... if they are small, manually merging isn't that big of a deal ... and if anyone else has been working in that code since release, there is a chance it won't mergef cleanly ... Quite frankly, I'm for pgindent after branch and before beta ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] Re: Call for platforms
On Thu, 22 Mar 2001, Thomas Lockhart wrote: Solaris x867.0 2000-04-12, Marc Fournier scrappy, do you still have this machine? Doing tests on Solaris x86/7 right now, will report as soon as they are done ... Solaris 2.5.1-2.7 Sparc 7.0 2000-04-12, Peter Eisentraut I'll bet that someone already has Solaris covered. Report? Will do up Sparc/7 also this morning ... AIX 4.3.3 RS6000 7.1 2001-03-21, Gilles Darold BeOS 5.0.3 x86 7.1 2000-12-18, Cyril Velter BSDI 4.01 x86 7.1 2001-03-19, Bruce Momjian Compaq Tru64 5.0 Alpha 7.0 2000-04-11, Andrew McMurry FreeBSD 4.2 x867.1 2001-03-19, Vince Vielhaber FreeBSD 4.3-BETA is good to go also ... ---(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] Re: Call for platforms
On Thu, 22 Mar 2001, Thomas Lockhart wrote: Solaris x86/7 results, for example, in geometry.out, show a difference of: 3,-3.06204718156754e-11 (expected) 3,-3.06204718035418e-11 (results) acceptable diviation? That sort of deviation is well within bounds, particularly for geometry tests which might have some transcendental math involved. Is Solaris-x86 ready to go then? Nope, still working through some things ... the select_implicit test failed completely: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress more results/select_implicit.out psql: connectDBStart() -- connect() failed: Connection refused Is the postmaster running locally and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? I'm going to re-run the test(s) and see if its an isolated thing or not ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] solaris 7/sparc good to go:
== shutting down postmaster ==
==
All 76 tests passed.
==
rm regress.o
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Re: Call for platforms
On Thu, 22 Mar 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Nope, still working through some things ... the select_implicit test failed completely: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress more results/select_implicit.out psql: connectDBStart() -- connect() failed: Connection refused Is the postmaster running locally and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? I'm going to re-run the test(s) and see if its an isolated thing or not ... Transient overflow of the postmaster socket's accept queue, maybe? How big is SOMAXCONN on your box? Okay, for me, solaris has always been a nemesis as I can never find anything on this box :( But, looking through the header files, I find: /usr/include/sys/socket.h:#define SOMAXCONN 5 I reran the tests two more times since the above ... first time went through clean as could be, with the geometry test failing (forgot to update my expected/resultmaps file(s) in my compile tree), the second time failed *totally* different tests then the first run: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress grep FAILED regression.out opr_sanity ... FAILED join ... FAILED aggregates ... FAILED arrays ... FAILED I ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Call for platforms
On Thu, 22 Mar 2001, Patrick Welche wrote: On Thu, Mar 22, 2001 at 12:49:39PM -0500, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: These are parallel tests right? What's the failure diffs? same as last time: dragon:/home/centre/marc/src/postgresql-7.1RC1/src/test/regress more results/opr_sanity.out psql: connectDBStart() -- connect() failed: Connection refused Is the postmaster running locally and accepting connections on Unix socket '/tmp/.s.PGSQL.65432'? See Peter's comment elsewhere that he doesn't think Solaris handles Unix socket connections very well. Try patching pg_regress to force unix_sockets=no. and yet another run (and different results): = 1 of 76 tests failed, 1 failed test(s) ignored. = That's just ye olde random "random" failure ... Funny, I get the more optimistic: == 75 of 76 tests passed, 1 failed test(s) ignored. == Different version? PostgreSQL 7.1RC1 7.1RC1 (the not released yet version) :) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Onject Database Survey ... Help needed ...
I recently got sent a survey to fill out that is meant to compare various
Object databases ... there are ~20 sections to this thing, asking
questions ranging from General Architecture to interactions with External
DBMSs ... and *alot* of questions that I've no experience in, and,
therefore, no answers to ...
I've HTMLized it as best as I can and put the resultant sections up at
http://www.postgresql.org/survey ...
I'm just starting to go through the sections, so right now, none of them
have answers yet ... if ppl could help by reading through and providing
answers so that I can provide as accurate of information as possible, it
should give for a good initial showing for PgSQL on the Object stage ...
I don't need the whole section answered ... for instance, there is a
section on Mapping_Objects_To_External_DBMS, that have sub-sections like:
===
C++ Map Generation Processing
This table describes the process for generating the mapping.
processing .h files
processing generated C++ files
external run-time via reflection
===
getting an email back with the section name and the sub-section
cut-n-paste with an appropriate 'Yes' or 'No' after each 'question' would
be great, and I'll merge that back into the HTML itself ...
Thanks ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Release Candidate 1 ...
On Fri, 23 Mar 2001, Gordon A. Runkle wrote: In article [EMAIL PROTECTED], "The Hermit Hacker" [EMAIL PROTECTED] wrote: Well, its been a hard, arduous journey for this one, with several delays caused by the massive amount of changes that have gone into v7.1 ... but, tonight I've finally wrapped up Release Candidate 1 ... Well, done, too! I've been banging on Beta6 with data and queries from DB2, and it's been the easiest transition I've ever had between RDBMSs. Will upgrading from Beta6 to RC1 require dumping and restoring databases? My understanding was that originally, there was a dump/reload required, but I believe that requirement was negated by a 'resetxlog' utility that Tom Lane created ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] CVS tags for betas and release candidate
On Mon, 26 Mar 2001, Matthias Juchem wrote: Hi there. I was just looking for the CVS tags for downloading the beta6 and the RC1 of 7.1 but there are only the following tags: REL_7_1_BETA2 REL_7_1_BETA3 REL_7_1 Aren't there tags for the versions I am looking for? Nope ... doing the tags didn't work as well as was hoped, so we've just been using date ranges instead ... release itself will be tag'd ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: Majordomo Delivery Error
gone
On Tue, 27 Mar 2001, Thomas Swan wrote:
At 3/27/2001 03:21 AM, [EMAIL PROTECTED] wrote:
This message was created automatically by mail delivery software.
A Majordomo message could not be delivered to the following addresses:
[EMAIL PROTECTED]:
450 4.7.1 [EMAIL PROTECTED]... Can not check MX records for
recipient host math.unl.edu.ar
-- Original message omitted --
I have received a ton of these during the last few days... can someone
please check to remove this address or correct the problem?
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Spinlocks on SGI's
On Tue, 27 Mar 2001, Robert E. Bruccoleri wrote: Dear Marc, On Tue, 27 Mar 2001, Robert E. Bruccoleri wrote: I contributed the first working s_lock.c code for the SGI's over three years ago (using the test_and_set library calls). It's been working for me ever since in a heavy multi-user environment. Please don't change it unless there's an overwhelming reason. Also, the GNU compiler systems works poorly on SGI's. In this environment, you need to stick to the SGI provided compilers. Once you get used to them, they work fairly well. Robert, any possibility of getting pre-compiled binaries for SGI that we can put up on the site? For those that can't afford the extra cost of the compilers? :) Yes. What exactly do you need from the Postgresql tree after a successful compilation and test? easiest, I think, unless SGI has a special packaging (pkg_add) format, is a tar of /usr/local/pgsql ... that *should* have everything required ... bin, libs and includes ... if you could create one based on RC1 and upload that, then we can get some testing on whether or not that works before the release? login info to follow ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Third call for platform testing
On Fri, 30 Mar 2001, Mathijs Brands wrote: On Fri, Mar 30, 2001 at 03:17:06PM +, Thomas Lockhart allegedly wrote: And here are the up-to-date platforms; thanks for the reports: SNIP Solaris 2.7 Sparc 7.1 2001-03-22, Marc Fournier Marc, was this done without unix sockets? nope, purely default ... it was only the x86 platform that I had a bugger with getting a clean regress working on ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] RC2 schedualed for Tomorrow evening ...
On Fri, 30 Mar 2001, Peter Eisentraut wrote: The Hermit Hacker writes: Just a heads up for anyone that might have something outstanding ... I'm going to package her early evening (~18:30AST) and announce it to both pgsql-hackers and pgsql-announce when done ... Once RC2 goes out, its meant to be a "this is what we'd release if docs were completely ready to go" ... AFAICT, we need to close out the platform list, re-generate INSTALL, and that's it. Bruce mentioned something about additional changes in HISTORY, though. right, that falls under the "this is what we'd release if docs were completely ready to go" :) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CVS commits
will still get into v7.1 *nod*
On Mon, 2 Apr 2001, Michael Meskes wrote:
Will current CVS commits make it into 7.1? Or do I have to use a different
branch. I just committed a minor patch to keep the parsers in sync and also
committed a bug fix last week. Both should be in 7.1.
Michael
--
Michael Meskes
[EMAIL PROTECTED]
Go SF 49ers! Go Rhein Fire!
Use Debian GNU/Linux! Use PostgreSQL!
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] All's quiet ... RC3 packaging ...
I packaged up an RC2 over the weekend, and pretty much as soon as I had it
packaged and in place, before I could announce it, there were several
patches thrown in ... so, I left it there, let anyone who happened to see
it pick it up, but didn't announce it ...
Everything has been quiet, as far as patches are concerned, for the past
24+hrs ... I'd like to roll (and actually announce) an solid RC3 tonight,
with announce first thing tomorrow morning, unless anyone has anythign
they aer sitting on?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] All's quiet ... RC3 packaging ...
On Wed, 4 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Everything has been quiet, as far as patches are concerned, for the past 24+hrs ... I'd like to roll (and actually announce) an solid RC3 tonight, with announce first thing tomorrow morning, unless anyone has anythign they aer sitting on? I think we've got to remove that failing horology test before we wrap RC3. can we comment out the test for now, so that its still in there, but not tested? or is there absolutely non way that we can fix that in the long term? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
RE: [HACKERS] All's quiet ... RC3 packaging ...
On Wed, 4 Apr 2001, Mikheev, Vadim wrote: Everything has been quiet, as far as patches are concerned, for the past 24+hrs ... I'd like to roll (and actually announce) an solid RC3 tonight, with announce first thing tomorrow morning, unless anyone has anythign they aer sitting on? We still have opened report about losing files after backend crash... No new input from Konstantin -:( if not easily recreateable, we can leave that one as somethign for v7.1.1 ... I'll run some tests... then again, if it is easily recreatable ... :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: All's quiet ... RC3 packaging ...
On Wed, 4 Apr 2001, Thomas Lockhart wrote: I've got patches for the regression tests to work around the "time with time zone" DST problem. Will apply to the tree asap, and will post a message when that is done. Sounds cool ... I'll scheduale an RC3 then, around that bug being fixed ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RC3 ... anyone have anything left outstanding?
Okay, unless I hear different from anyone out there, I'm goin to roll RC3
when I get to work tomorrow, and announce it before I leave (to give it
some time to propogate to the mirrors) ...
On Thu, 5 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Thomas? Did I miss your patch for the 'WITH TIMEZONE' regression test?
Still not there in CVS ...
Does anyone else have anything left outstanding that should hold me off
from doing an RC3 tomorrow?
Other than a better answer for the horology test, I think we are good
to go. The main thing that was still bothering me was Konstantin
Solodovnikov's report of database corruption. I just committed a fix
for the primary cause of that problem: turns out he was triggering a
random transfer of control inside plpgsql. (Calling through a
previously freed function pointer is uncool...) I'm guessing that the
ensuing corruption of the database can be blamed on whatever bit of code
managed to misexecute before the backend crashed completely. This is
plausible because he reports that he only saw corruption in perhaps one
out of every several hundred repetitions of the crash --- it makes sense
that you'd need to mistransfer just so to result in writing junk XLOG
entries or whatever was the direct cause of the data corruption.
Vadim is still poking at the test case Konstantin sent, but I'll bet
he won't be able to reproduce any corruption. The effects of jumping
through an overwritten function pointer would be exceedingly
system-specific.
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[HACKERS] Re: RC3 ...
On Fri, 6 Apr 2001, Thomas Lockhart wrote: The docs are ready for shipment. Even better ... Okay, let's let this sit as RC3 for the next week... I'll go ahead and start generating hardcopy, though I understand that it is no longer allowed into the shipping tarball :( At 2Meg, is there a reason why we include any of the docs as part of the standard tar ball? It shouldn't be required to compile, so should be able to be left out of the main tar ball and downloaded seperately as required .. thereby shrinking the distribution to 6Meg from its current 8 ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RC3 ...
On Fri, 6 Apr 2001, Bruce Momjian wrote: On Fri, 6 Apr 2001, Thomas Lockhart wrote: The docs are ready for shipment. Even better ... Okay, let's let this sit as RC3 for the next week... I'll go ahead and start generating hardcopy, though I understand that it is no longer allowed into the shipping tarball :( At 2Meg, is there a reason why we include any of the docs as part of the standard tar ball? It shouldn't be required to compile, so should be able to be left out of the main tar ball and downloaded seperately as required .. thereby shrinking the distribution to 6Meg from its current 8 ... Can we drop TODO.detail from the tarball too? No need to include that, I think. The web site has nice links to it now. Uncompressed it is 1.314 megs. Definitely, I think TODO.detail should be refer'd to by the TODO file, but not included in the distribution itself ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: RC3 ...
On Fri, 6 Apr 2001, Tom Lane wrote: At 2Meg, is there a reason why we include any of the docs as part of the standard tar ball? It shouldn't be required to compile, so should be able to be left out of the main tar ball and downloaded seperately as required .. thereby shrinking the distribution to 6Meg from its current 8 ... Can we drop TODO.detail from the tarball too? No need to include that, I think. The web site has nice links to it now. Uncompressed it is 1.314 megs. That strikes me as an awfully web-centric view of things. Not everyone has an always-on high-speed Internet link. If you want to make the docs and TODO.detail be a separate chunk of the split distribution, that's fine with me. But I don't agree with removing them from the full tarball. OTOH, if Marc was only thinking of removing the pre-built docs from the tarball, I don't object to that. I'm not sure why those weren't distributed as separate tarballs from the get-go. I just say that the doc sources are part of the source distribution... But, why? That sounds like a highly DSL-centric view of things *grin* If someone really wants docs, what hurts a second GET ftp call? ---(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] Re: RC3 ...
On Fri, 6 Apr 2001, Bruce Momjian wrote: That strikes me as an awfully web-centric view of things. Not everyone has an always-on high-speed Internet link. If you want to make the docs and TODO.detail be a separate chunk of the split distribution, that's fine with me. But I don't agree with removing them from the full tarball. OTOH, if Marc was only thinking of removing the pre-built docs from the tarball, I don't object to that. I'm not sure why those weren't distributed as separate tarballs from the get-go. I just say that the doc sources are part of the source distribution... But, why? That sounds like a highly DSL-centric view of things *grin* If someone really wants docs, what hurts a second GET ftp call? A major issue is that we don't regenerate docs for 7.1.1 or later, so the 7.1 docs carry for all the 7.1.X releases. That would seem to argue for a separate tarball for docs so people don't redownload the docs again for 7.1.1. Okay, unless someone can come up with a really good argument *for* why docs has to be included as part of the main tar file, I'm going to change the distributin generating script so that it generates a .src.tar.gz file seperate from the .doc.tar.gz file, which will make .src.tar.gz ~6Meg instead of the 8meg we are currently forcing ppl to download ... Peter E, is there anything part of the configure/make procedure that *requires* pgsql/doc to be there else it will break? If so, can you possibly put it as a test "if docs exists, deal with it, else ignore"? ---(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] Re: RC3 ...
On Sat, 7 Apr 2001, Lamar Owen wrote: The Hermit Hacker wrote: Okay, unless someone can come up with a really good argument *for* why docs has to be included as part of the main tar file, I'm going to change the distributin generating script so that it generates a .src.tar.gz file seperate from the .doc.tar.gz file, which will make .src.tar.gz ~6Meg instead of the 8meg we are currently forcing ppl to download ... Peter E, is there anything part of the configure/make procedure that *requires* pgsql/doc to be there else it will break? If so, can you possibly put it as a test "if docs exists, deal with it, else ignore"? We're going to do this at this point in the release cycle? IOW, is there going to be an RC4 with this new packaging, or is the first-off tarball with new packaging going to be the *final* 7.1 release *raised eyebrow*? there will be an RC4, I'm just waiting to hear back from Peter E as to whether there is anything in the build process we even risk breaking ... we've been doing the whole split thing for the past release or two as it is (the FreeBSD ports collection using the individual packages instead of the great big one) so from a packaging perspective, its well tested ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] A more useful way to split the distribution
Oh, I definitely like this ... and get rid of the *large* file, which will
save all the mirrors a good deal of space over time ...
On Sun, 8 Apr 2001, Peter Eisentraut wrote:
Since people suddenly seem to be suffering from bandwidth concerns I have
devised a new distribution split to address this issue. I propose the
following four sub-tarballs:
* postgresql-XXX.base.tar.gz 3.3 MB
Everything not in one of the ones below.
* postgresql-XXX.opt.tar.gz 1.7 MB
Everything not needed unless you use one of the following configure
options: --with-CXX --with-tcl --with-perl --with-python --with-java
--enable-multibyte --enable-odbc, plus some other not-really-needed
things.
The exact directory list is
src/bin/: pgaccess pgtclsh pg_encoding
src/interfaces: odbc libpq++ libpgtcl perl5 python jdbc
src/pl/: plperl tcl
src/backend/utils/mb contrib/retep src/tools build.xml
* postgresql-XXX.docs.tar.gz 1.9 MB
doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps
(Note man pages are in .base.)
* postgresql-XXX.test.tar.gz 1.0 MB
src/test
All this is proportionally about the same as right now, except that each
tarball except base would now be truly optional. So someone that only
wants to use, say, PHP and psql only needs to download the base package.
Patch below. Yes/no/maybe?
--- GNUmakefile.in Sun Apr 8 01:14:23 2001
+++ GNUmakefile2Sun Apr 8 01:19:55 2001
@@ -60,7 +60,7 @@
dist: $(distdir).tar.gz
ifeq ($(split-dist), yes)
-dist: $(distdir).base.tar.gz $(distdir).docs.tar.gz $(distdir).support.tar.gz
$(distdir).test.tar.gz
+dist: $(distdir).base.tar.gz $(distdir).docs.tar.gz $(distdir).opt.tar.gz
$(distdir).test.tar.gz
endif
dist:
-rm -rf $(distdir)
@@ -68,15 +68,22 @@
$(distdir).tar: distdir
$(TAR) chf $@ $(distdir)
+opt_files := $(addprefix src/bin/, pgaccess pgtclsh pg_encoding) \
+ $(addprefix src/interfaces/, odbc libpq++ libpgtcl perl5 python jdbc) \
+ $(addprefix src/pl/, plperl tcl) \
+ src/backend/utils/mb contrib/retep src/tools build.xml
+
+docs_files := doc/postgres.tar.gz doc/src doc/TODO.detail doc/internals.ps
+
$(distdir).base.tar: distdir
- $(TAR) -c $(addprefix --exclude $(distdir)/, doc src/test src/interfaces
src/bin) \
+ $(TAR) -c $(addprefix --exclude $(distdir)/, $(docs_files) $(opt_files)
src/test) \
-f $@ $(distdir)
$(distdir).docs.tar: distdir
- $(TAR) cf $@ $(distdir)/doc
+ $(TAR) cf $@ $(addprefix $(distdir)/, $(docs_files))
-$(distdir).support.tar: distdir
- $(TAR) cf $@ $(distdir)/src/interfaces $(distdir)/src/bin
+$(distdir).opt.tar: distdir
+ $(TAR) cf $@ $(addprefix $(distdir)/, $(opt_files))
$(distdir).test.tar: distdir
$(TAR) cf $@ $(distdir)/src/test
===snip
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] A more useful way to split the distribution
as soon as Peter commits the changes, I'll do up an RC4 with the new
format so that everyone can test it ...
On Sat, 7 Apr 2001, Lamar Owen wrote:
The Hermit Hacker wrote:
Oh, I definitely like this ... and get rid of the *large* file, which will
save all the mirrors a good deal of space over time ...
You gonna make a set of RC3 or 4 tarballs along these lines to test? I
want to try a build with this split before doing too much else -- well,
actually, I just want to make sure I get it right before release, as I'd
like to not have but a couple of days before an RPM release after the
announcement.
Sounds like a plan.
I'm going to upload a set of RC3 RPM's tonight -- there are changes that
I need people to comment upon.
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: RC3 ...
On Sat, 7 Apr 2001, Peter Eisentraut wrote: The Hermit Hacker writes: Okay, unless someone can come up with a really good argument *for* why docs has to be included as part of the main tar file, Because people want to read the documentation. get postgresql.src.tar.gz get postgresql.docs.tar.gz instead of just get postgresql.tar.gz for those that want to download the docs, same amount of time ... for those that don't want it, it sames them 2meg of download time ... I'm curious as to how many ppl would actually download those docs ... I know that I'd never do so, as I'm never on the same machine that the server is running from, so just hit the web site ... so, for those that do, we are giving them one extra step, and for those that don't, saving them time and bandwidth ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] release dates and announcements ?
Hi Peter ...
The problem this cycle has been that as soon as a package is ready
for announce, ppl have been cropping up with bugs that need to be fixed,
so we don't bother announcing it ... except to -hackers ...
We are currently at Release Candidate 3, with an RC4 most likely
going out tomorrow evening, which will also be announced to -announce as
the 'final release before release' ...
... and, if all goes well, the full relesae will be out on Friday
of this coming week ...
On Thu, 5 Apr 2001, Peter Galbavy wrote:
We are just (as per other queries recently) building a new system
using postgresql as the backend database. 7.1 seems like it is going
give us a number of essential fixes and useful features that make it
worth waiting a while.
As I have not seen announcements of the beta and RC cuts on
pgsql-announce, I would assume the development schedule is a more
closed thing than general chatter here, BUT is there an target
timetable for 7.1 (more that "when its ready" and subsequent 7.1.1
type releases ?
This information would help us decide whether to use an RC as a
development platform, moving to release later when we are ready to
test final work.
Also, would it be possible to announce alpha/beta/RC releases to
pgsql-announce ?
rgds,
--
Peter Galbavy
Knowledge Matters Ltd
http://www.knowledge.com/
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
On Sat, 7 Apr 2001, Lamar Owen wrote: One quick note -- since 'R' 'b', the RC RPM's must be forced to install with --oldpackage, as RPM does a simple strcmp of version numbers -- 7.1RC3 7.1beta1, for instance. Just force it with --oldpackage if you have a 7.1beta RPM already installed. Huh? I always thought that ASCII R was greater then b ... *confused* in the future, would it help to have 7.2Beta? Or am I missing something? :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
On Sun, 8 Apr 2001, Oliver Elphick wrote: The Hermit Hacker wrote: On Sat, 7 Apr 2001, Lamar Owen wrote: One quick note -- since 'R' 'b', the RC RPM's must be forced to install with --oldpackage, as RPM does a simple strcmp of version numbers -- 7.1RC3 7.1beta1, for instance. Just force it with --oldpackage if you have a 7.1beta RPM already installed. Huh? I always thought that ASCII R was greater then b ... *confused* in the future, would it help to have 7.2Beta? Or am I missing something? :) R = 82 b = 98 so b comes after R, and `blank' comes before either! Therefore 7.1 7.1RC 7.1beta ! As I suggested in another mail, let us switch to using even minor numbers for releases and odd ones for development: That means the final release of 7.1 will be called 7.2. Bugfix releases will then be 7.2.x. Meanwhile new development versions will be 7.3.x which will finally be released as 7.4, and so on... Not in this life time ... we are not going to move to a Linux-like development cycle ... *groan* ---(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] Re: A more useful way to split the distribution
On Sun, 8 Apr 2001, Peter Eisentraut wrote: I wrote: Since people suddenly seem to be suffering from bandwidth concerns I have devised a new distribution split to address this issue. I propose the following four sub-tarballs: * postgresql-XXX.base.tar.gz3.3 MB * postgresql-XXX.opt.tar.gz 1.7 MB * postgresql-XXX.docs.tar.gz1.9 MB * postgresql-XXX.test.tar.gz1.0 MB Since we're going to make a change, I'd like to change the names to postgresql-base-XXX.tar.gz etc. to align them with existing practice (cf. RPMs, GCC download). Dots should be used for format-identifying extensions. Go for it ... more a visual change then anything ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RPM upgrade caveats going from a beta version to RC
On Sun, 8 Apr 2001, Oliver Elphick wrote: The Hermit Hacker wrote:or development: That means the final release of 7.1 will be called 7.2. Bugfix releases will then be 7.2.x. Meanwhile new development versions will be 7.3.x which will finally be released as 7.4, and so on... Not in this life time ... we are not going to move to a Linux-like development cycle ... *groan* Harrumph!! Well, pick some scheme that gives a rational set of numbers for distributions. The current one is only good for installation by hand! We do, we follow the scheme as used by ... the BSD camp :) Be thankful we don't go all the way and use 7.2-RELEASE too :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] A more useful way to split the distribution
this only represents since 8:30am this morning ...
/source/v7.0.3/postgresql-7.0.3.support.tar.gz = 9
/source/v7.0.3/postgresql-7.0.3.test.tar.gz = 3
/source/v7.0.3/postgresql-7.0.3.docs.tar.gz = 10
/source/v7.0.3/postgresql-7.0.3.tar.gz = 22
/source/v7.0.3/postgresql-7.0.3.base.tar.gz = 9
on a side note, we almost have as many downloads of psqlodbc in that time
period:
/odbc/psqlodbc_home.html = 15
/odbc/versions/psqlodbc-07_01_0002.zip = 4
/odbc/versions/psqlodbc-07_01_0003.zip = 4
/odbc/versions/psqlodbc-07_01_0004.zip = 18
so it isn't a "fictitous crowd" that is going with the smaller chunks ...
its about 30% on a very small sample ...
On Sun, 8 Apr 2001, Peter Eisentraut wrote:
Christopher Sawtell writes:
For me and I expect many other folk on the edge of civilization it is a
total PITA to have to fiddle around and download many separate tarball
files. What I want is to be able to start a d/l going and then come back
when it's finished and know that I have _everything_ I actually need to
have a working and documented product in one shot.
Right. The only reason for splitting the distribution is to cater to the
fictitious crowd with "bandwidth problems" or those that explicitly know
that they don't need the rest. There will still be a canonical full
tarball with everything, or at least I will not put my name to something
that abolishes it. In fact, I didn't like the idea of the split tarballs
in the first place, I'm merely changing the split to something more
useful.
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Split Distro
On Mon, 9 Apr 2001, Henshall, Stuart - WCP wrote: When I downlaod a full tarball I want it all, I'm greedy like that. ;) If it is to be split up as standard I believe problems will arise with different versions being used together (by me most likley...). Also IMHO it will not necessarily be relised the docs have not been down loaded which means refering to older docs if there was a previous installation, or not finding any if no previous install. Also to prevent confusion it might be usefull to have the split distro in its own sub directory (eg Postgresql-7.1-Split-Distro, or somesuch), as when I first looked in on the download directory it was not imediatly obvious there was one main tarball and the rest where a split version rather than a main one with optional stuff (which is not my favoured option). Well, unless you have a broken client, the first thing you get when you enter the directory that the files are in is: = Information regarding the split distribution In the various download directories you will find alongside files with names like postgresql-XXX.tar.gz (where XXX is a version number) smaller files with the names postgresql-base-XXX.tar.gz postgresql-opt-XXX.tar.gz postgresql-docs-XXX.tar.gz postgresql-test-XXX.tar.gz The file named "postgresql-XXX.tar.gz" is the full source distribution. Each of the other four "tarballs" contains a subset of the files from the full distribution, for downloading convenience. If you download all four of them and unpack them into the same directory you will get exactly what you would have gotten had you downloaded the full distribution. The -base package is the only one that is required for successful installation. It contains the server and the essential client interfaces. The -opt package contains all parts whose compilation needs to be enabled explicitly. This includes the C++, JDBC, ODBC, Perl, Python, and Tcl interfaces, as well as multibyte support. The -docs package contains the documentation in HTML format (man pages are in -base) and the documentation sources. You don't need to download this package if you intend to browse the documentation on the web. Finally, the -test package contains the regression test suite. (Note, this scheme is new as of version 7.1RC4. Previous versions used a different, incompatible split where all subpackages where required.) === ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Truncation of char, varchar types
After v7.1 is released ... ?
On Mon, 9 Apr 2001, Peter Eisentraut wrote:
Excessively long values are currently silently truncated when they are
inserted into char or varchar fields. This makes the entire notion of
specifying a length limit for these types kind of useless, IMO. Needless
to say, it's also not in compliance with SQL.
How do people feel about changing this to raise an error in this
situation? Does anybody rely on silent truncation? Should this be
user-settable, or can those people resort to using triggers?
--
Peter Eisentraut [EMAIL PROTECTED] http://yi.org/peter-e/
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Going from 7.0.3 - 7.1 ...
Theoretically, should one be able to do:
pg_dumpall db.out
remove 7.0.3 bin, lib, data, etc
install 7.1 bin, lib, etc
initdb 7.1
psql template1 db.out
Basically, has anyone actually tried *that* yet and can report on whether
or not it works?
I'm just about to try it here, on 2gig of data, but if others have
experience with this, that would be great ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[HACKERS] HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1?
v7.0.3 database:
trends_acctng=# \d
List of relations
Name | Type | Owner
-+---+---
accounts| table | pgsql
admin | table | pgsql
calls | table | pgsql
comments| table | pgsql
cookies | table | pgsql
credit_card | table | pgsql
credits | table | pgsql
logs| table | pgsql
personal| table | pgsql
radhist | table | pgsql
radlog | table | pgsql
remote_host | table | pgsql
static_ip | table | pgsql
users | table | pgsql
(14 rows)
v7.1 database:
trends_acctng=# \d
List of relations
Name | Type | Owner
--+--+-
buy | table| jeff
buy_bid_seq | sequence | jeff
clients_c_id_seq | sequence | jeff
cppvad_clients | table| jeff
cppvad_clients_cc_id_seq | sequence | jeff
cppvad_info | table| jeff
cppvad_info_cid_seq | sequence | jeff
download | table| jeff
download_dlid_seq| sequence | jeff
exchange | table| jeff
exchange_exid_seq| sequence | jeff
gallery | table| scrappy
listing | table| area902
listing_lid_seq | sequence | area902
ndict10 | table| pgsql
ndict11 | table| pgsql
ndict12 | table| pgsql
ndict16 | table| pgsql
ndict2 | table| pgsql
ndict3 | table| pgsql
ndict32 | table| pgsql
ndict4 | table| pgsql
ndict5 | table| pgsql
ndict6 | table| pgsql
ndict7 | table| pgsql
ndict8 | table| pgsql
ndict9 | table| pgsql
projects | table| scrappy
thepress | table| jeff
thepress_id_seq | sequence | jeff
ticket | table| pgsql
ticket_comments | table| pgsql
ticket_ticket_id_seq | sequence | pgsql
ticket_times | table| pgsql
(34 rows)
all I did was use pg_dumpall from v7.0.3 to dump to a text file, and
"psql template1 dumpfile" to load it back in again ...
obviously this doesn't work like it has in the past?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can't import to v7.1?
No errors, nothing ... here is the backend: %bin/postmaster -D /usr/local/pgsql/data DEBUG: database system was shut down at 2001-04-10 15:04:08 ADT DEBUG: CheckPoint record at (0, 1522068) DEBUG: Redo record at (0, 1522068); Undo record at (0, 0); Shutdown TRUE DEBUG: NextTransactionId: 615; NextOid: 18720 DEBUG: database system is in production state DEBUG: copy: line 445, XLogWrite: new log file created - consider increasing WAL_FILES DEBUG: XLogWrite: new log file created - consider increasing WAL_FILES DEBUG: XLogWrite: new log file created - consider increasing WAL_FILES DEBUG: MoveOfflineLogs: remove and I ran the restore in 'script' to save everything, and as: psql -q template1 pg_dumpall.out and there are no errors in the resultant file ... For all intensive purposes, the restore *looked* clean ... but, going back and looking at the dump file, the dump wasn't clean *puzzled look* I'm going to have to look at this some more, but its pg_dumpall in v7.0.3 that is dumping the wrong data, not the restore :( all 77 databases got dump'd as the same database: You are now connected to database wind. wind=# \d List of relations Name | Type | Owner --+--+- buy | table| jeff buy_bid_seq | sequence | jeff clients_c_id_seq | sequence | jeff cppvad_clients | table| jeff cppvad_clients_cc_id_seq | sequence | jeff cppvad_info | table| jeff cppvad_info_cid_seq | sequence | jeff download | table| jeff download_dlid_seq| sequence | jeff exchange | table| jeff exchange_exid_seq| sequence | jeff gallery | table| scrappy listing | table| area902 listing_lid_seq | sequence | area902 ndict10 | table| pgsql ndict11 | table| pgsql ndict12 | table| pgsql ndict16 | table| pgsql ndict2 | table| pgsql ndict3 | table| pgsql ndict32 | table| pgsql ndict4 | table| pgsql ndict5 | table| pgsql ndict6 | table| pgsql ndict7 | table| pgsql ndict8 | table| pgsql ndict9 | table| pgsql projects | table| scrappy thepress | table| jeff thepress_id_seq | sequence | jeff ticket | table| pgsql ticket_comments | table| pgsql ticket_ticket_id_seq | sequence | pgsql ticket_times | table| pgsql (34 rows) wind=# \connect viper You are now connected to database viper. viper=# \d List of relations Name | Type | Owner --+--+- buy | table| jeff buy_bid_seq | sequence | jeff clients_c_id_seq | sequence | jeff cppvad_clients | table| jeff cppvad_clients_cc_id_seq | sequence | jeff cppvad_info | table| jeff cppvad_info_cid_seq | sequence | jeff download | table| jeff download_dlid_seq| sequence | jeff exchange | table| jeff exchange_exid_seq| sequence | jeff gallery | table| scrappy listing | table| area902 listing_lid_seq | sequence | area902 ndict10 | table| pgsql ndict11 | table| pgsql ndict12 | table| pgsql ndict16 | table| pgsql ndict2 | table| pgsql ndict3 | table| pgsql ndict32 | table| pgsql ndict4 | table| pgsql ndict5 | table| pgsql ndict6 | table| pgsql ndict7 | table| pgsql ndict8 | table| pgsql ndict9 | table| pgsql projects | table| scrappy thepress | table| jeff thepress_id_seq | sequence | jeff ticket | table| pgsql ticket_comments | table| pgsql ticket_ticket_id_seq | sequence | pgsql ticket_times | table| pgsql (34 rows) neat ... On Tue, 10 Apr 2001, Joel Burton wrote: On Tue, 10 Apr 2001, The Hermit Hacker wrote: all I did was use pg_dumpall from v7.0.3 to dump to a text file, and "psql template1 dumpfile" to load it back in again ... obviously this doesn't work like it has in the past? Marc -- Was there an error message during restore? I've been dumping/restoring w/7.1 since long before beta, w/o real problems, b
Re: [HACKERS] Re: HOLD THE PRESSES!! ... pg_dump from v7.0.3 can'timport to v7.1?
On Wed, 11 Apr 2001, Peter Eisentraut wrote: The Hermit Hacker writes: okay, not sure how we should document this, but apparently pg_dumpall doesn't work as the man page at: http://www.postgresql.org/users-lounge/docs/7.0/user/app-pgdumpall.htm appears to suggest: Now, I swore I did a 'setenv PGHOST db.hub.org' to get around it, and it still failed, but now its working ... most confusing :( But, still, pg_dumpall doesn't appear to accept the -h option in v7.0.3 Exactly right. Options to pg_dumpall are only "pg_dump options", which means things like -o or -d. But pg_dumpall also runs a few psqls, which don't see any of this. Okay, but, according to the man page, -h host *is* a pg_dump option ... pg_dump [ dbname ] pg_dump [ -h host ] [ -p port ] [ -t table ] [ -a ] [ -c ] [ -d ] [ -D ] [ -i ] [ -n ] [ -N ] [ -o ] [ -s ] [ -u ] [ -v ] [ -x ] [ dbname ] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Tag'd, packaged and ready to go ...
Well folks, I just fixed the CVS tags (renamed REL7_1 to REL7_1_BETA and
moved REL7_1 to today) and packaged up the release ... this is it, any new
fixes go into v7.1.1 ... :)
I'm preparing a formal PR/Announce, and will send that out later on this
evening, but want to give some of the mirror sites a chance to update
before doing such ...
If anyone wants to grab a copy of this, make sure there are no outstanding
issues with the packaging itself, please do ...
There are no changes between rc4 and full release, except that D'Arcy
removed a 'beta' comment from the Python interface ... so if you are
running rc4 now, no need to upgrade ...
Unless any major disagreements, I'd like to scheduale v7.1.1 now, for May
1st, at which time I'll do our normal branch for v7.2 ... so, if you are
sitting on any *bug fixes* for v7.1, plesae start shoving them in
effective this email ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Anyone have any good addresses ... ?
On Fri, 13 Apr 2001, Bruce Momjian wrote: Here is what we've always sent to to date ... anyone have any good ones to add? Addresses : [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Do we do freshmeat? Yup ... just submit'd the update ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Anyone have any good addresses ... ?
email added, thanks ...
On 13 Apr 2001, Matthew Rice wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Here is what we've always sent to to date ... anyone have any good ones
to add?
I think that this is still the moderator's address for comp.os.linux.announce:
[EMAIL PROTECTED]
--
matthew rice [EMAIL PROTECTED] starnix inc.
tollfree: 1-87-pro-linuxthornhill, ontario, canada
http://www.starnix.com professional linux services products
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Anyone have any good addresses ... ?
Freshmeat updated, Linuxtoday bookmarked ... thanks ;)
On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
On 13 Apr 2001, Trond Eivind [iso-8859-1] Glomsrød wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
Here is what we've always sent to to date ... anyone have any good ones
to add?
Addresses : [EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED],
[EMAIL PROTECTED]
Freshmeat, linuxtoday. If the release includes RPMs for Red Hat Linux,
redhat-announce is also a suitable location.
do you have email addresses fo freshmeat/linuxtoday? I have 6 web sites
that I have bookmarked for announces also, so if you have a good web URL,
I'll take those too ...
Seems to be web based (painful):
http://freshmeat.net/faq/view/20/
http://linuxtoday.com/contribute.php3
--
Trond Eivind Glomsrød
Red Hat, Inc.
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[HACKERS] Upgrade complete ... all went smooth ...
Just as an FYI for those considering the shift ... I just upgraded all of
my databases over to v7.1 from v7.0.3 and it was smooth as silk. The only
problems were having to compile and load a few modules from contrib that
some of my clients were using ...
Took about an hour and a half to do 100 databases ..
Very impressive ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Re: 7.1 RPMs
If someone wants to come up with an idea for name, i think that the whole
Win camp could be seperated also ...
pgsql-windows and pgsql-rpm ?
as far as newsgroups are concerned, they would both fall under ports:
comp.databases.postgresql.ports.linux.rpm
comp.databases.postgresql.ports.windows
I'm willing to create, as long as ppl are willing to use *shrug*
On Sat, 14 Apr 2001, Bruce Momjian wrote:
Do we need to start thinking about an RPM mailing list? Seems there is
lots of traffic.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
[HACKERS] Name - number ...
77 databases in data/base directory ... all number'd ...
select * from pg_database;
doesn't give me the reference to which directory is which database ... so
what table do we need to join on to get this information?
thanks ...
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: 7.1 RPMs
On Sat, 14 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: If someone wants to come up with an idea for name, i think that the whole Win camp could be seperated also ... pgsql-windows and pgsql-rpm ? A windows list seems like a good idea. But I'm not sure that a separate list for RPMs is a good idea. In the first place, it's fuzzy: is it to be used just for RPM packaging discussion, or is it going to draw off --- for example --- all bug reports from people who happen to have installed from RPM instead of source? I suppose the former is intended, but it's not going to be clear to people. I think we've already got too many lists with fuzzy boundaries. In the second place, the RPM packaging discussion is quite sporadic; I think the traffic would be nil except at times when Lamar is working on new RPMs. That's why I wasn't sure how to classify the RPM one ... I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: 7.1 RPMs
On Sat, 14 Apr 2001, Peter Eisentraut wrote: Bruce Momjian writes: Do we need to start thinking about an RPM mailing list? Seems there is lots of traffic. The traffic naturally peaks around release time, and this time especially because yours truly messed up the whole build system that the packagers were so careful to work around. I trust that in a few weeks we'll enter a new quiet period. My vote is that technical packaging discussions should go on -hackers just like a makefile discussion. Why not a "pgsql-build", or something like that, list? Where build/make file discussions can take place? Vs server issues? I'd really like to find some way of reducing traffic on -hackers like we did with -interfaces ... if we can come up with a good list for it ... pgsql-build (or a better name?) could be for RPM discussions, just as easy as Makefile/Configure discussions ... ---(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] Name - number ...
d'oh, should have extended my query ...
select oid,* from pg_database;
gives the directory name ...
thanks :)
On Sat, 14 Apr 2001, Bruce Momjian wrote:
77 databases in data/base directory ... all number'd ...
select * from pg_database;
doesn't give me the reference to which directory is which database ... so
what table do we need to join on to get this information?
thanks ...
Info is in pg_class.relfilenode. Now the big question is where do
database names go. My guess is pg_database.oid.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Re: 7.1 RPMs
On Sat, 14 Apr 2001, Peter Eisentraut wrote: The Hermit Hacker writes: I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? We have pgsql-ports, which isn't seeing too much traffic as it is. Seems like the cygwin people hang out there anyway. Ya, well, there is alot of traffic on -hackers that should probably be over there anyway *shrug* ---(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] Re: 7.1 RPMs
On Sat, 14 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: I like Lamar's suggestion of pgsql-cygwin though ... sound reasonable? Yes, that's probably better than pgsql-windows ... Done ... ---(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] Hey guys, check this out.
there is little, to nothing, factual about that whole article ...
"Great Bridge essentially gives away its open-source database application
at little cost..."
- thannk god I can get it completely for free, eh?
"Great Bridge executives say their licensing costs for the software..."
- someone want to tell me when they started charging licensing
costs?
"...nearly 25 years ago"
- I thought it was around '85? That's only 15 years ...
"Version 7.1, due to ship at the end of June..."
- should I pull what we've released? *raised eyebrow*
"...is the marketing and channel arm for PostgreSQL"
- they are?
I wonder, is Great Bridge going to step up and correct the *several*
mis-conceptions that have been touted in their name? There were alot of
quotes from GB in there, so I wonder ... ?
On Sat, 14 Apr 2001, Lamar Owen wrote:
http://www.crn.com/Sections/Fast_Forward/fast_forward.asp?ArticleID=25670
Marc will be pleased to note that the PostgreSQL project came out of the
FreeBSD project, and is Great Bridge's database. Gotta love
journalistic license.
--
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
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Hey guys, check this out.
okay, I didn't get a copy of it ... :(
On Sun, 15 Apr 2001, Vince Vielhaber wrote:
I rarely sign a note as the webmaster, I like to keep a low profile.
I just sent the witch a note and made it a point to let her know who
I am - and BCCd Marc. He can cross post it if he wishes. I also sent
it to the editor of that rag.
Vince.
On Sun, 15 Apr 2001, The Hermit Hacker wrote:
there is little, to nothing, factual about that whole article ...
"Great Bridge essentially gives away its open-source database application
at little cost..."
- thannk god I can get it completely for free, eh?
"Great Bridge executives say their licensing costs for the software..."
- someone want to tell me when they started charging licensing
costs?
"...nearly 25 years ago"
- I thought it was around '85? That's only 15 years ...
"Version 7.1, due to ship at the end of June..."
- should I pull what we've released? *raised eyebrow*
"...is the marketing and channel arm for PostgreSQL"
- they are?
I wonder, is Great Bridge going to step up and correct the *several*
mis-conceptions that have been touted in their name? There were alot of
quotes from GB in there, so I wonder ... ?
On Sat, 14 Apr 2001, Lamar Owen wrote:
http://www.crn.com/Sections/Fast_Forward/fast_forward.asp?ArticleID=25670
Marc will be pleased to note that the PostgreSQL project came out of the
FreeBSD project, and is Great Bridge's database. Gotta love
journalistic license.
--
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
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
Online Campground Directoryhttp://www.camping-usa.com
Online Giftshop Superstorehttp://www.cloudninegifts.com
==
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Re: 7.1 RPMs
On Sun, 15 Apr 2001, Thomas Lockhart wrote: Do we need to start thinking about an RPM mailing list? Seems there is lots of traffic. The delete key is your friend. So is procmail, if you just can't stand to see the letters "R", "P", and "M" too close together ;) I'm not a big fan of the trend to fork off a mailing list anytime more than a few messages on a single topic come through. The synergy and cross-pollination that we get by having us all see various topics wrt development far outweigh the minor annoyance to some on having to delete topics they don't find interesting. As an example, RPM building is only a part of the general packaging of PostgreSQL, but it illustrates issues which anyone touching configuration or Makefiles should be aware of. So forcing "those Linux people" onto some specialty list weakens the knowledge base we all could draw from. All imho of course... agreed, that's why I was kinda thinking maybe some sort of 'build' list ... something that deals with configure, makefile and packaging issues ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] CRN article
So, to sum up ... the article did a good job of representing Great Bridge,
did a great injustice (a slap in the face, so to say) to the PostgreSQL
community as a whole, so Great Bridge has no intention of correcting the
situation?
Just to clarify your position, of course ...
On Sun, 15 Apr 2001, Ned Lilly wrote:
Folks,
By now, I imagine a number of people have seen the piece on the
Computer Reseller News website about Great Bridge and PostgreSQL.
While I think we're all happy to see the increased visibility for
PostgreSQL (especially as compared to the Oracles of the world),
it's fair to say the article wasn't perfect. As Nathan Myers
observed in another post, they rarely are. ;-)
I thought the reporter did a good job of talking about Great
Bridge's business model and how we work with resellers and
third-party software developers (which after all is the focus of the
magazine). Sure, there were some minor errors of fact, like the
confusion over PostgreSQL's Berkeley origins, and the use of the
word "licensing."
But of greater concern to us, and the reason I'm writing this note,
is the lack of clarity about the open source community that has
built, and continues to build this software. Great Bridge is one
company, one member of a large community, and a relative newcomer to
the party. We employ several leading PostgreSQL developers, and
give back to the project in many ways, but at the end of the day,
we're still only a very small part of the larger project - which
precedes us by many years, and could very easily survive us as
well. We are *a* marketing channel for PostgreSQL (not *the*
channel), provide services around the software, and release a
QA-certified distribution (bundled with other tools and
applications), but we know that it's not *our* software. It's
everyone's, and I'm sorry the article didn't adequately represent
that reality.
Having said that, I'd ask everyone to take a deep breath, as Nathan
suggested, and realize that it's still early in the adoption cycle
for open source in the larger business world and the mass media.
There will continue to be nuances that seem blindingly obvious to
us, but slip right through the reporting and editing process in the
trade press. That's ok, as long as we correct those errors, as
delicately as possible ;-)
We all have a shared stake in PostgreSQL being more widely used and
appreciated, and how we respond to things like this will go a long
way toward furthering that goal. You can all be justifiably proud
of the work that's gone into PostgreSQL, leading up to the terrific
7.1 release; a big part of Great Bridge's job as a marketing
organization is to make sure the world finds out about it - an
ongoing job that we take very seriously.
If anyone has any questions about Great Bridge's position on this
kind of stuff, please feel free to email me off-list.
Thanks,
Ned
--
Ned Lilly e: [EMAIL PROTECTED]
Vice Presidentw: www.greatbridge.com
Evangelism / Hacker Relationsv: 757.233.5523
Great Bridge, LLCf: 757.233.
---(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
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Fast Forward (fwd)
On Sat, 14 Apr 2001, Nathan Myers wrote: This is probably a good time to point out that this is the _worst_ _possible_ response to erroneous reportage. The perception by readers will not be that the reporter failed, but that PostgreSQL advocates are rabid weasels who don't appreciate favorable attention, and are favorable attention?? dangerous to write anything about. You can bet this reporter and her editor will treat the topic very circumspectly (i.e. avoid it) in the future. woo hoo, if that is the result, then I think Vince did us a great service, not dis-service ... Most reporters are ignorant, most reporters are lazy, and many are both. It's part of the job description. Getting angry about it is like getting angry at birds for fouling their cage. Their job is to regurgitate what they're given, and quickly. They have no time to learn the depths, or to write coherently about it, or even to check facts. Out of all the articles on PgSQL that I've read over the years, this one should have been shot before it hit the paper (so to say) ... it was the most blatantly inaccurate article I've ever read ... It will be harder than the original mailings, but I urge each who wrote to write again and apologize for attacking her. In a way, I think you are right .. I think the attack was aimed at the wrong ppl :( She obviously didn't get *any* of her information from ppl that belong *in* the Pg community, or that have any knowledge of how it works, or of its history :( ---(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] Fast Forward (fwd)
the thing that pissed me off the most, and set me off, was the totally
blatant errors ... we've had other articles written, with a GB slant to
them, that didn't get my feathers in a ruffle ... the fact that they
*talked* with GB, got quotes from them and some of their partners, and
*still* got the facts wrong, is what got me heated ...
On Sun, 15 Apr 2001, Bruce Momjian wrote:
Here's my response to the inaccurate article cmp produced. After
chatting with Marc I decided to post it myself.
Since I know Ned reads this list, I formally request that he also
insists PUBLICALLY that cmp correct their inaccuracies. I'm rather
disappointed (for lack of a more descriptive word) that Bruce has not
already done so.
OK, I read the article. Seems there are two major mistakes. First,
they equate Great Bridge with PostgreSQL, and second, they don't know
the history of PostgreSQL.
If they fixed those two mistakes, the article would be OK. Seems like
they have already been contacted and hopefully they will correct this.
(Not sure how they do that.)
In reading the article, I have to ask myself, "How upset would I be if
they had equated PostgreSQL, Inc or another company with PostgreSQL?"
Well, I certainly wouldn't like it, and would try to get it corrected.
However, I wouldn't consider it a major problem. The press makes
mistakes like this all the time, and this press outlet is just too small
to worry about.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Re: [BUGS] three VERY minor things with 7.1 final
On Tue, 17 Apr 2001, Tom Lane wrote: David George [EMAIL PROTECTED] writes: I just built the postgresql 7.1 final and the configure script is still checking for sfio. Not a major big deal, but I need to remove the sfio check from configure.in, run autoconf, and then configure to fix it. If you remember sfio on Sparc Solaris 7 was causing a segfault when psql would display its output. Hmm. Digging in the CVS logs and pghackers archives, it seems that configure started checking for sfio in response to Michael Richards' unsubstantiated claim that FreeBSD 2.2.5 requires it to be used (http://www.postgresql.org/mhonarc/pgsql-hackers/1998-04/msg00363.html). Can anyone confirm or deny that? Marc had previously expressed some interest as well (thread starting at http://www.postgresql.org/mhonarc/pgsql-hackers/1998-04/msg00219.html) but the outcome of that thread didn't seem to suggest that it's a must-have item. Damn, now *that* is an old thread ... I can't see any reason why it would be required for FreeBSD, as its only a port for the OS, not part of it ... I'm tempted to rip out the configure check for sfio, but if it's only broken on some systems and really is useful on others, then we have to try to figure out how to tell if it's broken :-( Pull it, as far as I'm conerned ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Another news story in need of 'enlightenment'
I can't seem to get at the original anymore, but we talked to Dr.
Soparkar, and is posted a 'followup' of the article to:
http://linuxtoday.com/news_story.php3?ltsn=2001-04-16-009-21-PS-EL-HE-0038
Since I can't seem to get to the original on dqindia.com, I can't comment
on what's changed ...
On Wed, 18 Apr 2001, D'Arcy J.M. Cain wrote:
Thus spake Lamar Owen
This one probably needs the 'iron hand and the velvet paw' touch. The
iron hand to pound some sense into the author, and the velvet paw to
make him like having sense pounded into him. Title of article is 'Open
Source Databases Won't Fly' --
http://www.dqindia.com/content/enterprise/datawatch/101041201.asp
I'm not sure there was even a point in there. The article was rambling
and undirected. Completely apart from any content, this just seemed like
a badly written article. I'm not sure that it even merits consideration
in this forum.
I guess anyone can be published on the net.
--
D'Arcy J.M. Cain darcy@{druid|vex}.net | Democracy is three wolves
http://www.druid.net/darcy/| and a sheep voting on
+1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] idle processes in v7.1 ... not killable?
I tried to do a 'kill pid' like I would have in v7.0.3, doesn't affect
it ... so, how to get rid of idle process that have been sitting around
for a long time, without having to shutdown the database itself?
pgsql 64484 0.0 1.0 15352 10172 p4- ISat08PM 0:00.15 postmaster: hordemgr
horde 216.126.85.170 idle (postgres)
pgsql 64760 0.0 1.0 15352 10420 p4- ISat08PM 0:00.21 postmaster: hordemgr
horde 216.126.85.170 idle (postgres)
pgsql 94615 0.0 0.8 15336 8488 p4- ISun12AM 0:00.09 postmaster: hordemgr
horde 216.126.85.86 idle (postgres)
pgsql 99711 0.0 0.9 15336 9688 p4- ISun01AM 0:00.14 postmaster: hordemgr
horde 216.126.85.188 idle (postgres)
pgsql 99810 0.0 0.9 15352 9124 p4- ISun01AM 0:00.12 postmaster: hordemgr
horde 216.126.85.188 idle (postgres)
pgsql1768 0.0 0.8 15336 8112 p4- ISun01AM 0:00.09 postmaster: hordemgr
horde 216.126.85.86 idle (postgres)
pgsql8781 0.0 1.1 15368 11016 p4- ISun09AM 0:00.23 postmaster: hordemgr
horde 216.126.85.30 idle (postgres)
pgsql 29503 0.0 1.1 15352 11052 p4- ISun10AM 0:00.23 postmaster: hordemgr
horde 216.126.85.30 idle (postgres)
pgsql 29930 0.0 1.0 15352 10556 p4- ISun11PM 0:00.15 postmaster: hordemgr
horde 216.126.85.100 idle (postgres)
pgsql 29985 0.0 1.0 15352 10192 p4- ISun11PM 0:00.14 postmaster: hordemgr
horde 216.126.85.100 idle (postgres)
pgsql 57446 0.0 0.6 15336 6784 p4- IMon09AM 0:00.06 postmaster: hordemgr
horde 216.126.85.243 idle (postgres)
pgsql 57961 0.0 0.7 15336 6884 p4- IMon09AM 0:00.06 postmaster: hordemgr
horde 216.126.85.243 idle (postgres)
pgsql 98541 0.0 0.8 15352 8756 p4- IMon11AM 0:00.10 postmaster: hordemgr
horde 216.126.85.13 idle (postgres)
pgsql 98601 0.0 0.7 15336 6796 p4- IMon11AM 0:00.06 postmaster: hordemgr
horde 216.126.85.13 idle (postgres)
pgsql 16510 0.0 0.7 15352 7624 p4- IMon01PM 0:00.07 postmaster: hordemgr
horde 216.126.85.196 idle (postgres)
pgsql 17052 0.0 0.7 15352 6936 p4- IMon01PM 0:00.06 postmaster: hordemgr
horde 216.126.85.196 idle (postgres)
pgsql 86741 0.0 0.6 15336 6660 p4- IMon10PM 0:00.06 postmaster: hordemgr
horde 216.126.85.119 idle (postgres)
pgsql8388 0.0 0.6 15336 6484 p4- ITue12AM 0:00.05 postmaster: hordemgr
horde 216.126.85.95 idle (postgres)
pgsql 27186 0.0 1.0 15368 10880 p4- ITue09AM 0:00.24 postmaster: hordemgr
horde 216.126.85.184 idle (postgres)
pgsql 27512 0.0 0.9 15352 9616 p4- ITue09AM 0:00.15 postmaster: hordemgr
horde 216.126.85.184 idle (postgres)
pgsql 91723 0.0 1.0 15368 10364 p4- ITue12PM 0:00.16 postmaster: hordemgr
horde 216.126.85.194 idle (postgres)
pgsql 45351 0.0 0.6 15336 5952 p4- I10:03AM 0:00.04 postmaster: hordemgr
horde 216.126.85.186 idle (postgres)
pgsql 35967 0.0 0.5 15336 4960 ?? I 8:53AM 0:00.03 postmaster: hordemgr
horde 216.126.84.1 idle (postgres)
pgsql 36678 0.0 0.0 1008 312 p4 R+8:55AM 0:00.00 grep hordemgr
pgsql 45200 0.0 0.7 15356 6828 p4- I10:03AM 0:00.06 postmaster: hordemgr
horde 216.126.85.186 idle (postgres)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] idle processes in v7.1 ... not killable?
Okay, I *swear* I tried both 'kill pid' and 'kill -TERM pid' this
morning before I sent this out .. just tried it again and it worked :(
*shrug*
On Thu, 19 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
I tried to do a 'kill pid' like I would have in v7.0.3, doesn't affect
it ...
Huh? Doesn't kill default to -TERM on your machine? That works fine
for me ...
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] CVS server ailing?
try now?
On Thu, 19 Apr 2001, Peter Eisentraut wrote:
What did you do to the CVS server? It takes hours to update a single
file, half a day to run cvs diff. This has been like that for about 48
hours.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] refusing connections based on load ...
Anyone thought of implementing this, similar to how sendmail does it? If load n, refuse connections? Basically, if great to set max clients to 256, but if load hits 50 as a result, the database is near to useless ... if you set it to 256, and 254 idle connections are going, load won't rise much, so is safe, but if half of those processes are active, it hurts ... so, if it was set so that a .conf variable could be set so that max connection == 256 *or* load n to refuse connections, you'd hvae best of both worlds ... sendmail does it now, and, apparently relatively portable across OSs ... okay, just looked at the code, and its kinda painful, but its in src/conf.c, as a 'getla' function ... If nobody is working on something like this, does anyone but me feel that it has merit to make use of? I'll play with it if so ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
On Mon, 23 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: sendmail does it now, and, apparently relatively portable across OSs ... sendmail expects to be root. It's unlikely (and very undesirable) that postgres will be installed with adequate privileges to read /dev/kmem, which is what it'd take to run the sendmail loadaverage code on most platforms... Actually, not totally accurate ... sendmail has a 'RunAs' option for those that don't wish to have it run as root, and still works for the loadavg stuff, to the best of my knowledge (its an option I haven't played with yet) ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
other then a potential buffer overrun, what would be the problem with:
open(kmem)
read values
close(kmem)
?
I would think it would be less taxing to the system then doing a system()
call, but still effectively as safe, no?
On Mon, 23 Apr 2001, Tom Lane wrote:
The Hermit Hacker [EMAIL PROTECTED] writes:
On Mon, 23 Apr 2001, Tom Lane wrote:
sendmail expects to be root.
Actually, not totally accurate ... sendmail has a 'RunAs' option for those
that don't wish to have it run as root,
True, it doesn't *have* to be root, but the loadavg code still requires
privileges beyond those of mere mortals (as does listening on port 25,
last I checked).
On my HPUX box:
$ ls -l /dev/kmem
crw-r- 1 binsys 3 0x01 Jun 10 1996 /dev/kmem
so postgres would have to run setuid bin or setgid sys to read the load
average. Either one is equivalent to giving an attacker the keys to the
kingdom (overwrite a few key /usr/bin/ executables and wait for root to
run one...)
On Linux and BSD it seems to be more common to put /dev/kmem into a
specialized group kmem, so running postgres as setgid kmem is not so
immediately dangerous. Still, do you think it's a good idea to let an
attacker have open-ended rights to read your kernel memory? It wouldn't
take too much effort to sniff passwords, for example.
Basically, if we do this then we are abandoning the notion that Postgres
runs as an unprivileged user. I think that's a BAD idea, especially in
an environment that's open enough that you might feel the need to
load-throttle your users. By definition you do not trust them, eh?
A less dangerous way of approaching it might be to have an option
whereby the postmaster invokes 'uptime' via system() every so often
(maybe once a minute?) and throttles on the basis of the results.
The reaction time would be poorer, but security would be a whole lot
better.
regards, tom lane
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] refusing connections based on load ...
On 23 Apr 2001, Ian Lance Taylor wrote: Tom Lane [EMAIL PROTECTED] writes: On Linux and BSD it seems to be more common to put /dev/kmem into a specialized group kmem, so running postgres as setgid kmem is not so immediately dangerous. Still, do you think it's a good idea to let an attacker have open-ended rights to read your kernel memory? It wouldn't take too much effort to sniff passwords, for example. On Linux you can get the load average by doing `cat /proc/loadavg'. On NetBSD you can get the load average via a sysctl. On those systems and others the uptime program is neither setuid nor setgid. Good call ... FreeBSD has it also, and needs no special privileges ... just checked, and the sysctl command isn't setuid/setgid anything, so I'm guessing that using sysctl() to pull these values shouldn't create any security issues on those systems that support it ? ---(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] OUTER JOIN vs UNION ... faster?
Got a query that looks like:
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send0,card_info,category_details
WHERE send0.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
AND card_info.main_cat=category_details.category
AND send_date = '2001/04/08'
AND send_date = '2001/05/14' group by 1,2
UNION ALL
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send1,card_info,category_details where send1.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
AND card_info.main_cat=category_details.category
AND send_date = '2001/04/08'
AND send_date = '2001/05/14' group by 1,2
UNION ALL
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send2,card_info,category_details where send2.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
AND card_info.main_cat=category_details.category
AND send_date = '2001/04/08'
AND send_date = '2001/05/14' group by 1,2
UNION ALL
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send3,card_info,category_details where send3.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
AND card_info.main_cat=category_details.category
AND send_date = '2001/04/08'
AND send_date = '2001/05/14' group by 1,2
UNION ALL
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send4,card_info,category_details where send4.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
AND card_info.main_cat=category_details.category
AND send_date = '2001/04/08'
AND send_date = '2001/05/14' group by 1,2
UNION ALL
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send5,card_info,category_details where send5.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
AND card_info.main_cat=category_details.category
AND send_date = '2001/04/08'
AND send_date = '2001/05/14' group by 1,2
UNION ALL
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
FROM send6,card_info,category_details where send6.card_id=card_info.card_id
AND category_details.mcategory='e-cards'
AND card_info.main_cat=category_details.category
AND send_date = '2001/04/08'
AND send_date = '2001/05/14' group by 1,2
UNION ALL
SELECT card_info.main_cat, category_details.sub_cat_flag,count(*)
*Really* dreading the thought of changing it to an OUTER JOIN, and am
wondering if there would be a noticeable speed difference between going
from the UNION above to an OUTER JOIN, or should they be about the same?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] refusing connections based on load ...
Apparently so under Solaris ...
hestia:/ uname -a
SunOS hestia 5.7 Generic_106542-12 i86pc i386 i86pc
C Library Functionsgetloadavg(3C)
NAME
getloadavg - get system load averages
SYNOPSIS
#include sys/loadavg.h
int getloadavg(double loadavg[], int nelem);
DESCRIPTION
How hard would it be to knock up code that, by default, ignores loadavg,
but if, say, set in postgresql.conf:
loadavg = 4
it will just refuse connections?
On Tue, 24 Apr 2001, Peter Eisentraut wrote:
Tom Lane writes:
The Hermit Hacker [EMAIL PROTECTED] writes:
sendmail does it now, and, apparently relatively portable across OSs ...
sendmail expects to be root. It's unlikely (and very undesirable) that
postgres will be installed with adequate privileges to read /dev/kmem,
which is what it'd take to run the sendmail loadaverage code on most
platforms...
This program:
#include stdio.h
int main()
{
double la[3];
if (getloadavg(la, 3) == -1)
perror(getloadavg);
printf(%f %f %f\n, la[0], la[1], la[2]);
return 0;
}
works unprivileged on Linux 2.2 and FreeBSD 4.3. Rumour[*] also has it
that there is a way to do this on Solaris and HP-UX 9. So I think that
covers enough users to be worthwhile.
[*] - Autoconf AC_FUNC_GETLOADAVG
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Re: Re: refusing connections based on load ...
On Wed, 25 Apr 2001, Lincoln Yeoh wrote: At 10:59 PM 23-04-2001 -0700, Nathan Myers wrote: On Tue, Apr 24, 2001 at 12:39:29PM +0800, Lincoln Yeoh wrote: Why not be more deterministic about refusing connections and stick to reducing max clients? If not it seems like a case where you're promised something but when you need it, you can't have it. The point is that number of connections is a very poor estimate of system load. Sometimes a connection is busy, sometimes it's not. Actually I use number of connections to estimate how much RAM I will need, not for estimating system load. Because once the system runs out of RAM, performance drops a lot. If I can prevent the system running out of RAM, it can usually take whatever I throw at it at near the max throughput. I have a Dual-866, 1gig of RAM and strip'd file systems ... this past week, I've hit many times where CPU usage is 100%, RAM is 500Meg free and disks are pretty much sitting idle ... It turns out, in this case, that vacuum was in order (i vacuum 12x per day now instead of 6), so that now it will run with 300 simultaneous connections, but with a loadavg of 68 or so, 300 connections are just building on each other to slow the rest down :( ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Re: refusing connections based on load ...
On Tue, 24 Apr 2001, Nathan Myers wrote: On Tue, Apr 24, 2001 at 11:28:17PM -0300, The Hermit Hacker wrote: I have a Dual-866, 1gig of RAM and strip'd file systems ... this past week, I've hit many times where CPU usage is 100%, RAM is 500Meg free and disks are pretty much sitting idle ... Assuming strip'd above means striped, it strikes me that you might be much better off operating the drives independently, with the various tables, indexes, and logs scattered each entirely on one drive. have you ever tried to maintain a database doing this? PgSQL is definitely not designed for this sort of setup, I had symlinks goign everywhere,a nd with the new numbering schema, this is even more difficult to try and do :) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
On Wed, 25 Apr 2001, Peter Eisentraut wrote: Tom Lane writes: A conncurrent-xacts limit isn't perfect of course, but I think it'd be pretty good, and certainly better than anything based on the available load-average numbers. The concurrent transaction limit would allow you to control the absolute load of the PostgreSQL server, but we can already do that and it's not what we're after here. The idea behind the load average based approach is to make the postmaster respect the situation of the overall system. Additionally, the concurrent transaction limit would only be useful on setups that have a lot of idle transactions. Those setups exist, but not everywhere. To me, both of these approaches are in the if you don't like it, don't use it category. Agreed ... by default, the loadavg method could be set to zero, to ignore ... I don't care if I'm off by 1min before I catch the increase, the fact is that I have caught it, and prevent any new ones coming in until it drops off again ... Make it two variables: transla rejectla if transla is hit, restrict on transactions, letting others connect, but putting them on hold while the la drops again ... if it goes above rejectla, refuse new connections altogether ... so now I can set something like: transla = 8 rejectla = 16 but if loadavg goes above 16, I want to get rid of what is causing the load to rise *before* adding new variables to the mix that will cause it to rise higher ... and your arg about permissions (Tom's, not Peter's) is moot in at least 3 of the major systems (Linux, *BSD and Solaris) as there is a getloadavg() function in all three for doing this ... ---(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] refusing connections based on load ...
On Wed, 25 Apr 2001, Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: The idea behind the load average based approach is to make the postmaster respect the situation of the overall system. That'd be great if we could do it, but as I pointed out, the available stats do not allow us to do it very well. I think this will create a lot of portability headaches for no real gain. If it were something we could just do and forget, I would not object --- but the porting issues will create a LOT more work than I think this can possibly be worth. The fact that the work is distributed and will mostly be incurred by people other than the ones advocating the change doesn't improve matters. As I mentioned, getloadavg() appears to be support on 3 of the primary platforms we work with, so I'd say for most installations, portability issues aren't an issue ... Autoconf has a 'LOADAVG' check already, so what is so problematic about using that to enabled/disable that feature? If ( loadavg available on OSenabled in postgresql.conf ) operate on it } else ( loadavg not available on OS enabled ) noop with a WARN level error that its not available } ---(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] refusing connections based on load ...
On Wed, 25 Apr 2001, Vince Vielhaber wrote: On Wed, 25 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Autoconf has a 'LOADAVG' check already, so what is so problematic about using that to enabled/disable that feature? Because it's tied to a GNU getloadavg.c implementation, which we'd have license problems with using. It's part of the standard C library in FreeBSD. Any other platforms have it built in? As has been mentioned, Solaris and Linux also have it ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] refusing connections based on load ...
On Wed, 25 Apr 2001, Tom Lane wrote: I'm still concerned about portability issues, and about whether load average is really the right number to be looking at, however. Its worked for Sendmail for how many years now, and the code is there to use, with all portability issues resolved for every platform they use ... and a growing number of platforms appear to have the mechanisms already built into their C libraries ... ---(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] refusing connections based on load ...
On Thu, 26 Apr 2001, Vince Vielhaber wrote: On Wed, 25 Apr 2001, The Hermit Hacker wrote: On Wed, 25 Apr 2001, Vince Vielhaber wrote: On Wed, 25 Apr 2001, Tom Lane wrote: The Hermit Hacker [EMAIL PROTECTED] writes: Autoconf has a 'LOADAVG' check already, so what is so problematic about using that to enabled/disable that feature? Because it's tied to a GNU getloadavg.c implementation, which we'd have license problems with using. It's part of the standard C library in FreeBSD. Any other platforms have it built in? As has been mentioned, Solaris and Linux also have it ... But what's in FreeBSD's standard library isn't GNU. Wouldn't matter if it was, its part of the OSs standard library ... unless you mean to pull it in and use it with the distribution, which I think might be a bad idea ... if we pull anything in, sendmail's would be best ... FreeBSD's will have had anything required for non-FreeBSD systems yanked out, if it was ever there, while sendmail's already has all the 'hooks' in it ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] The new, the improved ... FTS Searching of Mailing List Archives
Morning all ...
I'm going to do a broader announcement in a couple of days, but
Oleg and his gang have just finished setting up their Mailing List
Searching software ...
If you go to fts.postgresql.org, it is like night-day as far as
the old searching is concerned ...
We have some more configuration work to do on it, to improve
performance, but if anyone has used the old interface, performance now is
such that even without much tuning on the backend, you no longer have time
for coffee between searches :)
Try it, let us know of any bugs, and we'll do a bigger
announcement in a couple of days to the rest of the community ...
Vince, can you fix the search links to point to this, as far as
the mailing list searches are concerned? docs are still in udmsearch for
now ...
*Major* thanks to Oleg and his group for making this available
to the community ... now searching is a useful function :)
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Re: The new, the improved ... FTS Searching of Mailing List Archives
Actually, default appears to be the last month worth of messages ... check
your date range :)
On Fri, 27 Apr 2001, Vince Vielhaber wrote:
On Fri, 27 Apr 2001, The Hermit Hacker wrote:
Morning all ...
I'm going to do a broader announcement in a couple of days, but
Oleg and his gang have just finished setting up their Mailing List
Searching software ...
If you go to fts.postgresql.org, it is like night-day as far as
the old searching is concerned ...
We have some more configuration work to do on it, to improve
performance, but if anyone has used the old interface, performance now is
such that even without much tuning on the backend, you no longer have time
for coffee between searches :)
Try it, let us know of any bugs, and we'll do a bigger
announcement in a couple of days to the rest of the community ...
Vince, can you fix the search links to point to this, as far as
the mailing list searches are concerned? docs are still in udmsearch for
now ...
*Major* thanks to Oleg and his group for making this available
to the community ... now searching is a useful function :)
It *is* alot quicker. I did a search for scrappy on All Lists and
it came back in 0.151 secs. But it only found 104 matches, have you
been that quiet Marc?
I'll add it over the weekend.
Vince.
--
==
Vince Vielhaber -- KA8CSHemail: [EMAIL PROTECTED]http://www.pop4.net
56K Nationwide Dialup from $16.00/mo at Pop4 Networking
Online Campground Directoryhttp://www.camping-usa.com
Online Giftshop Superstorehttp://www.cloudninegifts.com
==
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] The new, the improved ... FTS Searching of MailingList Archives
On Fri, 27 Apr 2001, Bruce Momjian wrote: Vince, can you fix the search links to point to this, as far as the mailing list searches are concerned? docs are still in udmsearch for now ... *Major* thanks to Oleg and his group for making this available to the community ... now searching is a useful function :) And something to add to 7.2! Huh? *raised eyebrow* This is a standalone application that they've donated to the project ... nothing that can be added to any of our distributions ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] The new, the improved ... FTS Searching of MailingList Archives
On Fri, 27 Apr 2001, Bruce Momjian wrote: On Fri, 27 Apr 2001, Bruce Momjian wrote: Vince, can you fix the search links to point to this, as far as the mailing list searches are concerned? docs are still in udmsearch for now ... *Major* thanks to Oleg and his group for making this available to the community ... now searching is a useful function :) And something to add to 7.2! Huh? *raised eyebrow* This is a standalone application that they've donated to the project ... nothing that can be added to any of our distributions ... Isn't the text indexing something that can go into the distribution? to the best of my knowledge, everything they had for public consumption was added to v7.1, but Oleg would be better for that ... to get fts.postgresql.org, there was nothing special I had to do as far as the backend was concerned *shrug* ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Split of tree on May 1
On Fri, 27 Apr 2001, Bruce Momjian wrote: We have discussed splitting the tree on May 1 to start 7.2 development. If no one objects, we will stay with that schedule. Please see other thread where we are actually discussing this ... if you have anything to add to that thread please do so ... ---(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] WAL feature
On Fri, 27 Apr 2001, Mikheev, Vadim wrote: Row reuse without vacuum Yes, it will help to remove uncommitted rows. Same question as I asked Bruce ... how? :) I wasn't trying to be fascisious(sp?) when I asked, I didn't realize the two were connected and am curious as to how :) ---(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] WAL feature
On Fri, 27 Apr 2001, Bruce Momjian wrote: How? I guess other hosts could read the WAL to find out what changed. I wonder if that would get around one of the issues I had brought up a ways back concerning replication and stuff like sequences ... Row reuse without vacuum How? Didn't even see these as being related ... It may be. Not sure. Neither am I ... Vadim seems to think so, so am curious as to how ... ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
RE: [HACKERS] WAL feature
On Fri, 27 Apr 2001, Mikheev, Vadim wrote: Row reuse without vacuum Yes, it will help to remove uncommitted rows. Same question as I asked Bruce ... how? :) I wasn't trying to be fascisious(sp?) when I asked, I didn't realize the two were connected and am curious as to how :) After implementing UNDO operation (we have only REDO now) transactions will roll back their changes on abort and so free space occupied by inserted rows. Ahhh, okay, so this isn't reusing space on delete/update, so much as avoiding writing to the table until the transaction is committed? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
[HACKERS] v7.1.1 branched and released on Tuesday ...
As Tom's mentioned the other day, we're looking at doing up v7.1.1 on
Tuesday, and starting in on v7.2 ...
Does anyone have any outstanding fixes for v7.1.x that they want to see in
*before* we do this release? Any points unresolved that anyone knows
about that we need to look at?
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(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] Thanks, naming conventions, and count()
doesn't this defeat the reasons for going to numerics? is there a reason
why its such a difficult thing to do a SELECT oid on pg_database and
pg_class to get this information? that's what I've been doing when I need
to know *shrug*
On Sun, 29 Apr 2001, Bruce Momjian wrote:
First off I just wanted to give a big 'thank you' to all the
developers and contributors who have made PostgreSQL what it is
today. I haven't come across a single thing since my first
experience with it a few years ago that hasn't been corrected,
sped up, or otherwise postively enhanced!
In working with 7.1 over the past couple weeks, I've noted the
following mods may add to usability and speed:
o v7.1 changed the database naming convention to be all numeric;
I suggest having
the DB engine create symbolic links when creating a new DB
and subsequent tables. For instance, in creating a database
'foo' with table 'bar' the /path/to/pgsql/data/base folder
will have a new folder named something like '18720'; this
folder could also have a symbolic link to 'foo'. Then in the
'18720' folder rather than just having numeric files for each
table, pk, index, etc. there could be symbolic links
following the naming convention 'bar', 'pk_foo_pkey',
'field1_foo_ukey', 'field2_foo_key'.
Maybe this would work best as configurable flag that could
be set during compilation or in the conf file.
I think this is an excellent idea, and will add it to the TODO list. We
agonized over moving to numeric names, and we couldn't think of a good
way to allow administrators to know that table matched what files. The
big problem is that there is no good way to make the symlinks reliable
because in a crash, the symlink could point to a table creation that got
rolled back or the renaming of a table that got rolled back. I think
symlinks with some postmaster cleanup script that fixed bad symlinks
would be great for 7,2.
I have added this to the TODO list. If someone objects, I will remove
it:
* Add tablename symlinks for numeric file names
o count() should use index scans for tables with a PK; scans
would be on the PK index;
even after running 'vacuum analyze' such a query still uses
a sequential scan. For instance, select count(*) from bar
and even select(pk_name) from bar both use sequential scans.
Likewise, scans on fields with indexes should use the index.
The problem here is that now we don't have commit status in the index
rows, so they have to check the heap for every row. One idea is to
update the index status on an index scan, and if we can do that, we can
easily use the index. However, the table scan is pretty quick.
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup.| Drexel Hill, Pennsylvania 19026
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary: scrappy@{freebsd|postgresql}.org
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
Re: [HACKERS] Thanks, naming conventions, and count()
On Sun, 29 Apr 2001, Bruce Momjian wrote: doesn't this defeat the reasons for going to numerics? is there a reason why its such a difficult thing to do a SELECT oid on pg_database and pg_class to get this information? that's what I've been doing when I need to know *shrug* Yes, but you can't do that if you can't start the database or can't connect for some reason. If people don't think it is worthwhile, we can delete the TODO item. Okay, what does being able to ls the directory give you if you can't start the database? the only thing I do it for is to figure out whicih tables are taking up so much disk space, or which databases ... For example, when someone has trouble figuring out which directory is which database, they can just ls and look at the symlinks. Seems like a nice feature. Ya, but I thought that the reason for going numeric had to do with being transaction safe ... something about being able to safely RENAME a table, if my recollection remotely comes close ... as soon as you start throwing around symlinks, do we break that once more? what about if someone wants to physically move a table to a seperate file system, which is something that has been suggested as a way around the fact that all files are in the same subdirectory? You have a symlink to the symlink? I don't know the answers to these questions, which is why I'm asking them ... if this is something safe to do, and doesn't break us again, then sounds like a good idea to me too ... ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
Re: [HACKERS] Thanks, naming conventions, and count()
On Sun, 29 Apr 2001, Bruce Momjian wrote: I don't know the answers to these questions, which is why I'm asking them ... if this is something safe to do, and doesn't break us again, then sounds like a good idea to me too ... I was suggesting the symlinks purely for admin convenience. The database would use only the numeric names. Except that the database would have to maintain those links ... now you've given something ppl are relying on being there, but, for some reason, a symlink wasn't created, so they think their table doesn't exist? I can even think of a situation, as unlikely as it can be, where this could happen ... run out of inodes on the file system ... last inode used by the table, no inode to stick the symlink onto ... its a remote situation, but I've personally had it happen ... I'd personally prefer to see some text file created in the database directory itself that contains the mappings ... so that each time there is a change, it just redumps that data to the dext file ... less to maintain overall ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Thanks, naming conventions, and count()
On Sun, 29 Apr 2001, Bruce Momjian wrote: I can even think of a situation, as unlikely as it can be, where this could happen ... run out of inodes on the file system ... last inode used by the table, no inode to stick the symlink onto ... If you run out of inodes, you are going to have much bigger problems than symlinks. Sort file creation would fail too. its a remote situation, but I've personally had it happen ... I'd personally prefer to see some text file created in the database directory itself that contains the mappings ... so that each time there is a change, it just redumps that data to the dext file ... less to maintain overall ... Yes, I like that idea, but the problem is that it is hard to update just one table in the file. You sort of have to update the entire file each time a table changes. That is why I liked symlinks because they are per-table, but you are right that the symlink creation could fail because the new table file was never created or something, leaving the symlink pointing to nothing. Not sure how to address this. Is there a way to update a flat file when a single table changes? Why not just dump the whole file? That way, if a previosu dump failed for whatever reason, the new dump would correct that omission ... Then again, why not some sort of 'lsdb' command that looks at where it is and gives you info as appropriate? if in data/base, then do a connect to template1 using postgres so that you can dump and parse the raw data from pg_database ... if in a directory, you should be able to connect to that database in a similar way to grab the contents of pg_class ... no server would need to be running for this to work, and if it was readonly, it should be workable if a server is running, no? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Thanks, naming conventions, and count()
On Sun, 29 Apr 2001, Bruce Momjian wrote: Yes, I like that idea, but the problem is that it is hard to update just one table in the file. You sort of have to update the entire file each time a table changes. That is why I liked symlinks because they are per-table, but you are right that the symlink creation could fail because the new table file was never created or something, leaving the symlink pointing to nothing. Not sure how to address this. Is there a way to update a flat file when a single table changes? Why not just dump the whole file? That way, if a previosu dump failed for whatever reason, the new dump would correct that omission ... Yes, you can do that, but it is only updated during a dump, right? Makes it hard to use during the day, no? Then again, why not some sort of 'lsdb' command that looks at where it is and gives you info as appropriate? I want to do that for oid2name. I had the plan layed out, but never got to it. if in data/base, then do a connect to template1 using postgres so that you can dump and parse the raw data from pg_database ... if in a directory, you should be able to connect to that database in a similar way to grab the contents of pg_class ... no server would need to be running for this to work, and if it was readonly, it should be workable if a server is running, no? I think parsing the file contents is too hard. The database would have to be running and I would use psql. I don't know, I recovered someone's database using a raw connection ... wasn't that difficult once I figured out the format *shrug* the following gets the oid,relname's for a database in the format: echo select oid,relname from pg_class | postgres -L -D /usr/local/pgsql/data eceb | egrep oid|relname then just parse the output using a simple perl script: 1: oid = 163338 (typeid = 26, len = 4, typmod = -1, byval = t) 2: relname = auth_info_uid_key (typeid = 19, len = 32, typmod = -1, byval = f) 1: oid = 163341 (typeid = 26, len = 4, typmod = -1, byval = t) 2: relname = auth_info_id(typeid = 19, len = 32, typmod = -1, byval = f) 1: oid = 56082 (typeid = 26, len = 4, typmod = -1, byval = t) 2: relname = auth_info (typeid = 19, len = 32, typmod = -1, byval = f) the above won't work on a live database, did try that, so best is to test for a connection first, and this would be a fall back ... but you'd at least have a live *and* non live way of parsing the data *shrug* ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
