Re: [HACKERS] 7.3: Change in cursor behavior?
On Wed, Dec 04, 2002 at 12:22:41AM +, Sigurdur Gunnlaugsson wrote: test=# move -10 in test_c; MOVE 4 test=# fetch 1 from test_c; schemaname | tablename | tableowner | hasindexes | hasrules | hastriggers +---+++--+- (0 rows) I have not tried 7.3 final so I can't say if this happens there also. Seems to be fixed in 7.4devel. Thanks for the data! So this might be a bug in 7.3? Perhaps the cursor thinks it's at position -6 then and fetches no rows until it gets back to zero... Jeroen ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
-Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED]] Sent: 03 December 2002 23:34 To: Justin Clift Cc: Dave Page; Marc G. Fournier; Bruce Momjian; PostgreSQL-development Subject: Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces Justin Clift writes: Of course we are, it's just that we're also trying to direct people to the Advocacy site where there is a lot more info, in a lot more languages. Why don't we just shut down the regular web site. Clearly it's not considered adequate anymore. Strangely I was just thinking the same thing. If all the info is on advocacy, then what exactly will be left on the main site? Idocs? I was sort of under the impression that the site reshuffle was happening in a top down manner anyway - start with the portal, then sort out the less-immediately-visible lower bits. I'll preempt the 'this was all discussed on -advocacy, you should have been there' response with yet another agreement with Vince :-) - I too am getting far too much mail these days and another list is the last thing I need. Regards, Dave. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Please, apply patch of tsearch for current CVS 7.3.1
Thank you very much, you catch it :). This bug had a long life, because it exists if and only if locale of postmaster was a different from C (or ru_RU.KOI8-R). Please, apply patch for current CVS 7.3.1 Magnus Naeslund(f) wrote: Ok, I nailed the bug, but i'm not sure what the correct fix is. Attached tsearch_morph.diff that remedies this problem by avoiding it. Also there's a debug aid patch if someone would like to know how i finally found it out :) There problem in the lemmatize() function is that GETDICT(...) returned a value not handled (BYLOCALE). The value (-1) and later used as an index into the dicts[] array. After that everything went berserk stack went crazy somehow so trapping the fault sent me to the wrong place, and every time i read the value it was positive ;) So now i just return the initial word passed to the lemmatize function, because i don't know what to do with it. So you tsearch guys will have to work it out :) -- Teodor Sigaev [EMAIL PROTECTED] tsearch_patch.gz Description: application/gzip ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] PQnotifies() in 7.3 broken?
Thanks to Rod Taylor's kind help in donating a system account, I've been able to test libpqxx against postgres 7.3. Unfortunately, I'm running into several problems. One thing that broke libpqxx was a change in cursor behaviour that according to Sigurdur Gunnlaugsson seems to be gone in the 7.4 development tree. But I'm hitting other snags as well. When receiving a trigger notification under 7.3, the structure returned by PQnotifies() appears to be bogus. In a test I ran, its be_pid was consistently zero and its relname pointed into never-neverland. Has anyone else come across this? Jeroen ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Broadcast replication (Was Re: [HACKERS] 7.4 Wishlist)
- Original Message - From: Kevin Brown [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, December 03, 2002 8:49 PM Subject: [mail] Re: [HACKERS] 7.4 Wishlist Al Sutton wrote: Point to Point and Broadcast replication With point to point you specify multiple endpoints, with broadcast you can specify a subnet address and the updates are broadcast over that subnet. The difference being that point to point works well for cross network replication, or where you have a few replicants. I have multiple database servers which could have a deadicated class C network that they are all on, by broadcasting updates you can cutdown the amount of traffic on that net by a factor of n minus 1 (where n is the number of servers involved). Yech. Now you can't use TCP anymore, so the underlying replication code has to handle all the issues that TCP deals with transparently, like error checking, retransmits, data windows, etc. I don't think it's wise to assume that your transport layer is 100% reliable. Further, this doesn't even address the problem of bringing up a leaf server that's been down a while. It can be significantly out of date relative to the other servers on the subnet. I suspect you'll be better off implementing a replication protocol that has the leaf nodes keeping each other up to date, to minimize the traffic coming from the next level up. Then you can use TCP for the connections but minimize the traffic generated by any given node. I wasn't saying that ALL replication traffic must be broadcast, if a specific server needs a refresh when it comes then point to point is fine because only one machine needs the data, and thus broadcasting it to all would load machines with data they didn't need. The aim of using broadcast is to cut down the ongoing traffic, say, for example, I have a cluster of ten database servers I can connect them onto a dedicated LAN shared only by database servers and I would see 10% of the traffic I would get if I were using point to point (this is assuming that the addition of error checking, retransmits, etc. to the broadcast protocol adds a similiar overhead per packet as TCP point to point). If others wish to know more about this I can prepare an overview for how I see it working. [Other points snipped] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] unofficial 7.3 RPMs
On Mon, 2002-12-02 at 23:59, Joe Conway wrote: I've hacked the spec file from a 7.2.x source RPM to produce a 7.3 source RPM. I've also created a set of i686 binary RPMs. These are *not* official PGDG RPMs, and I'm not an RPM expert by any means (so use at your own risk!), but I've posted them in case anyone is interested. I'll leave them up until Lamar gets time to create the official set. http://www.joeconway.com/ Thanks, they seem to work fine. Except that I had to tweak the startup script - as distributed it defines the version to be 7.3b2 and checks database for version 7.2. It also expects/puts the database in nonstandard place. But otherways they saved me a lot of trouble ;) --- Hannu ---(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] A thank you from an end user
Hi everyone, We just received this message through the contact form on the Advocacy site. Thought it would be nice to hear. :-) (btw Ajay, you're probably best to upgrade to PostgreSQL 7.2.3 or 7.3 [just released], as 7.2.1 had a few nasty bugs in it) Regards and best wishes, Justin Clift Original Message Subject: A within the next day or two request for a PostgreSQL contact from advocacy.postgresql.org Date: Tue, 3 Dec 2002 08:50:32 -0500 (EST) From: Advocacy Website [EMAIL PROTECTED] Ajay Narke has requested to be contacted in regards to PostgreSQL. Email address : [EMAIL PROTECTED] Preferred language : English The nature of the request : I am a user of PostgreSQL 7.2.1. It's been a great experiance. PostgreSQL + RedHat Linux + Java Servlets + HTML make a very formidable combination. Congratulations to all those in development team. The region of the requester : INDIA The name of the requester's company : Narke Associates The number of people in the requester's company : 20 The urgency of the request is : 2 -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
Dave Page wrote: snip Strangely I was just thinking the same thing. If all the info is on advocacy, then what exactly will be left on the main site? Idocs? Good point, and worth thinking about then. I was sort of under the impression that the site reshuffle was happening in a top down manner anyway - start with the portal, then sort out the less-immediately-visible lower bits. I'll preempt the 'this was all discussed on -advocacy, you should have been there' response with yet another agreement with Vince :-) - I too am getting far too much mail these days and another list is the last thing I need. Ok then, what do you suggest? :-) Regards and best wishes, Justin Clift Regards, Dave. -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
-Original Message- From: Justin Clift [mailto:[EMAIL PROTECTED]] Sent: 04 December 2002 10:59 To: Dave Page Cc: Peter Eisentraut; Marc G. Fournier; Bruce Momjian; PostgreSQL-development Subject: Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces I'll preempt the 'this was all discussed on -advocacy, you should have been there' response with yet another agreement with Vince :-) - I too am getting far too much mail these days and another list is the last thing I need. Ok then, what do you suggest? Not sure, but we do need to define the roles of the groups and keep them seperate as much as possible otherwise some of us are gonna overload. I'm sure Vince will have something to say about this, but it seems to me that advocacy should define what the urghmarketing/urgh plan should be, and should look like, then the www people should implement it. Having the www people maintaining most sites, then the advocacy people doing their own thing seperately is a recipe for trouble. Think about how this would work in a commercial organisation - you would not have the web team sitting in on all the marketing meetings. We also have the advantage that our marketing people (== advocacy) are technically knowledgable and will not make idiots of themselves on a regular basis by asking us for impossible things - unlike your regular run-of-the-mill marketing drones :-) Regards, Dave. ---(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] [GENERAL] PostgreSQL Global Development Group Announces
On Tue, 3 Dec 2002, Vince Vielhaber wrote: Yup, as with doing anything for the firs ttime, the press release itself had its 'bugs' ... considering how many times Josh asked for comments on it, I'm surprised that nobody picked up on it *shrug* I understood it was intentional so comments wouldn't have done any good. Anything is only as intentional as nobody making constructive critisms of it ... e, that was major bad english ... not part of solution, you are part of problem sort of thing... ---(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] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002, Peter Eisentraut wrote: Marc G. Fournier writes: Yup, as with doing anything for the firs ttime, the press release itself had its 'bugs' ... considering how many times Josh asked for comments on it, I'm surprised that nobody picked up on it *shrug* And how should we have guessed that release management is now done by the advocacy group? While you're out advocating, don't forget the existing users. It isn't, but those working on -advocacy were asked to help come up with a stronger release *announcement* then we've had in the past ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002, Justin Clift wrote: Dave Page wrote: snip I could have sworn we used to have a bunch of ftp mirrors for downloads. Come to think of it I rewrote/stole a load of Vince's PHP code to allow you to select one from the portal recently. Are we not using them anymore? Of course we are, it's just that we're also trying to direct people to the Advocacy site where there is a lot more info, in a lot more languages. The only reason for the download page not having a list of mirrors is due to not having done it yet. So as to not recreate the wheel, or, at least, get the wheel properly rolling, can we get that download page redirected to the one that does list the mirrors? :) I liked Greg(?)'s ideas, but I don't see it as being implemented overnight :) ---(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] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002, Peter Eisentraut wrote: Justin Clift writes: Of course we are, it's just that we're also trying to direct people to the Advocacy site where there is a lot more info, in a lot more languages. Why don't we just shut down the regular web site. Clearly it's not considered adequate anymore. As of yet, the new portal isn't ready yet ... and the adequacy of the existing site isn't so much a problem, but maintainability of it ... according to Vince, trying to add anything to it is virtually impossible :( ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002, Dave Page wrote: I'll preempt the 'this was all discussed on -advocacy, you should have been there' response with yet another agreement with Vince :-) - I too am getting far too much mail these days and another list is the last thing I need. And I'll pre-empt *that* with the volume of email isn't changing, only the ability to filter that email ... the purpose of the -advocacy list is to focus on how to better market the software ... not through stuff like advertising, but how do we provide information to debunk alot of the out-dated myths that still float around ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002, Marc G. Fournier wrote: On Tue, 3 Dec 2002, Vince Vielhaber wrote: Yup, as with doing anything for the firs ttime, the press release itself had its 'bugs' ... considering how many times Josh asked for comments on it, I'm surprised that nobody picked up on it *shrug* I understood it was intentional so comments wouldn't have done any good. Anything is only as intentional as nobody making constructive critisms of it ... e, that was major bad english ... not part of solution, you are part of problem sort of thing... That may be how you understood it, but not how I understood it. There appears to be an incremental takeover occurring. Vince. -- http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
Marc G. Fournier wrote: snip So as to not recreate the wheel, or, at least, get the wheel properly rolling, can we get that download page redirected to the one that does list the mirrors? :) Yep. Would the best way to do this be changing the wording to say something like: PostgreSQL can be downloaded as source code from any of the many mirror sites: With a link after it directing to somewhere that gives the list. The present www.postgresql.org with the list of mirrors would probably be adequate, but it'll need to be a different url than the straight www.postgresql.org as that's going to change as soon as the new portal is in place. Does this sound like a workable approach for now? Regards and best wishes, Justin Clift I liked Greg(?)'s ideas, but I don't see it as being implemented overnight :) -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002, Marc G. Fournier wrote: On Wed, 4 Dec 2002, Peter Eisentraut wrote: Marc G. Fournier writes: Yup, as with doing anything for the firs ttime, the press release itself had its 'bugs' ... considering how many times Josh asked for comments on it, I'm surprised that nobody picked up on it *shrug* And how should we have guessed that release management is now done by the advocacy group? While you're out advocating, don't forget the existing users. It isn't, but those working on -advocacy were asked to help come up with a stronger release *announcement* then we've had in the past ... That wasn't stronger, it was fluffier. It was full of buzzwords that were masking the actual content. Are you trying to hide the accomplishments or promote them? If you're trying to hide them like in this announcement you may want to try using this tool: http://www.dack.com/web/bullshit.html The stored phrases are much more refined and better paired. Vince. -- http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002, Dave Page wrote: And I'll pre-empt *that* with the volume of email isn't changing, only the ability to filter that email ... the purpose of the -advocacy list is to focus on how to better market the software ... not through stuff like advertising, but how do we provide information to debunk alot of the out-dated myths that still float around ... Which is perfectly fine, but as one of the web site developers, I don't want to have to sit in on all the marketing threads to know what they want done with the websites. Instead I'd rather the discussions are summarized by one the the guys there (you/Justin/Bruce?), and they present that to -www and say 'this is what we think is good, please make it happen', at which point I can start coding. Ah, okay, that makes sense ... sort of allocate a 'liason' between the groups ... ? ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] MySQL update
On Tue, 3 Dec 2002, Christopher Kings-Lynne wrote: Not that anyone cares, but I notice in the commit logs for MySQL 4.1, it now has subselects. Any idea of which database you have to compile with MySQL to get that functionality? You aren't saying they actually did something for themselves this time, are you? :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Wishlist for 7.4: Plan stability
Greg Stark [EMAIL PROTECTED] writes: Really it boils down to one point: there's really no reason to assume a user should be able to execute any new query he feels like. Creating a new query should be privileged operation just like creating a new table or new database. This is an interesting view of what a database should be like, but it has very little to do with my idea of a database ;-). I think you want some sort of middleware layer to keep your users away from the database. I do not agree that the DB itself ought to contain such draconian restrictions. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] big text field - message type 0x44
Hi, I've been trying to ask on general, and tried to search the archives without much result, so I'll try here. I'm using PostgreSQL 7.2.1 on Solaris 8/sparc. In a table, I have a text field, which may contain long ascii strings. However, when trying to put data larger than about 32000 characters (probably 32767), I get various errors in different situations. I'll try to list the ones I've seen here, hoping that it will help you find the problem. Using libpq from my application, connecting to localhost:5432, I can insert large ascii strings to the field using the INSERT command, but I cannot get it with SELECT. I then get a message type 0x44 arrived from server while idle error. Using libpq from my application, connecting to the unix socket, I'm unable to insert the large ascii string. I get a PGRES_NONFATAL_ERROR, but no text message is available, i.e. PQresultErrorMessage(result) returns an empty string. When running SELECT here, I still get the message type 0x44 error. Using psql connecting to either unix socket or localhost:5432, I can run the same SELECT and the correct data is printed. The same application and PostgreSQL version running in Linux works well, so I've only seen this on Solaris. Since it works in psql, it must be possible for my application to work too, but I just can't figure out why it doesn't. Are there known problems with large strings on Solaris? Greetings, Tomas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [ADMIN] how to alter sequence.
On 4 Dec 2002 at 20:41, Hannu Krosing wrote: hannu=# update seq set max_value = 99; ERROR: You can't change sequence relation seq hannu=# update pg_class set relkind = 'r' where relname = 'seq'; UPDATE 1 hannu=# update seq set max_value = 99; UPDATE 1 hannu=# update pg_class set relkind = 'S' where relname = 'seq'; UPDATE 1 hannu=# select * from seq; sequence_name | last_value | increment_by | max_value | min_value | cache_value | log_cnt | is_cycled | is_called ---++--+---+---+-+-+---+--- seq | 1 |1 |99 | 1 | 1 | 1 | f | f That makes me wonder. If sequense is treated like a single column single row table and it's value is guarenteed to be increasing even in case of aborted transaction, is it correct to say that postgresql already has nested transactions, albeit dormant? Bye Shridhar -- Zero Defects, n.: The result of shutting down a production line. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002, Marc G. Fournier wrote: On Wed, 4 Dec 2002, Peter Eisentraut wrote: Justin Clift writes: Of course we are, it's just that we're also trying to direct people to the Advocacy site where there is a lot more info, in a lot more languages. Why don't we just shut down the regular web site. Clearly it's not considered adequate anymore. As of yet, the new portal isn't ready yet ... and the adequacy of the existing site isn't so much a problem, but maintainability of it ... according to Vince, trying to add anything to it is virtually impossible :( I have a new design for it, now it's just getting the time to implement it. It's easy to add to and looks alot nicer. Vince. -- http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(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] [GENERAL] PostgreSQL Global Development Group Announces
-Original Message- From: Marc G. Fournier [mailto:[EMAIL PROTECTED]] Sent: 04 December 2002 13:56 To: Dave Page Cc: Peter Eisentraut; Justin Clift; Bruce Momjian; PostgreSQL-development Subject: RE: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces On Wed, 4 Dec 2002, Dave Page wrote: And I'll pre-empt *that* with the volume of email isn't changing, only the ability to filter that email ... the purpose of the -advocacy list is to focus on how to better market the software ... not through stuff like advertising, but how do we provide information to debunk alot of the out-dated myths that still float around ... Which is perfectly fine, but as one of the web site developers, I don't want to have to sit in on all the marketing threads to know what they want done with the websites. Instead I'd rather the discussions are summarized by one the the guys there (you/Justin/Bruce?), and they present that to -www and say 'this is what we think is good, please make it happen', at which point I can start coding. Ah, okay, that makes sense ... sort of allocate a 'liason' between the groups ... ? Sounds spot on to me. Regards, Dave. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002, Marc G. Fournier wrote: On Wed, 4 Dec 2002, Dave Page wrote: I'll preempt the 'this was all discussed on -advocacy, you should have been there' response with yet another agreement with Vince :-) - I too am getting far too much mail these days and another list is the last thing I need. And I'll pre-empt *that* with the volume of email isn't changing, only the ability to filter that email ... the purpose of the -advocacy list is to focus on how to better market the software ... not through stuff like advertising, but how do we provide information to debunk alot of the out-dated myths that still float around ... But we *are* filtering. I'm filtering out all mail from -advocacy. Besides, I already got off of lists that I wanted to be on due to the traffic. Now you want me to join one that I don't want to be on so I can get more traffic? I've seen how well filters work. I've asked you questions that I never did get an answer to. How is that any better than not getting the mail to begin with? Vince. -- http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] interesting difference for queries...
I noticed an interesting difference in query behaviour: cms=# CREATE TABLE foo(bar int); CREATE cms=# SELECT * from foo where bar=1.7; bar - (0 rows) cms=# SELECT * from foo where bar='1.7'; ERROR: pg_atoi: error in 1.7: can't parse .7 Is this the same problem as index usage with/without quotes? However, one would expect the same output from both queries, either the error message, or better the 0 rows result. Regards Mario Weilguni ---(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] PQnotifies() in 7.3 broken?
Jeroen T. Vermeulen [EMAIL PROTECTED] writes: When receiving a trigger notification under 7.3, the structure returned by PQnotifies() appears to be bogus. In a test I ran, its be_pid was consistently zero and its relname pointed into never-neverland. We changed the PQnotifies result structure in 7.3 (to insulate clients from the value of NAMEDATALEN). I think you are compiling your app with a 7.3 libpq header and then running it with 7.2 libpq code, or possibly vice versa. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] interesting difference for queries...
On Wed, 2002-12-04 at 11:21, Mario Weilguni wrote: I noticed an interesting difference in query behaviour: cms=# CREATE TABLE foo(bar int); CREATE cms=# SELECT * from foo where bar=1.7; This is a numeric to integer coercion, which rounds rbt=# select 1.7::int; int4 -- 2 (1 row) bar - (0 rows) cms=# SELECT * from foo where bar='1.7'; ERROR: pg_atoi: error in 1.7: can't parse .7 This is a text to integer coercion, which doesn't round. I guess the question is whether or not a numeric - integer conversion should 'wedge' numbers into the int, or throw an error. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] PQnotifies() in 7.3 broken?
Perhaps the .so name should have been updated for PostgreSQL 7.3? For example in 7.2 libpq is: /usr/lib/libpq.so - libpq.so.2.2 /usr/lib/libpq.so.2 - libpq.so.2.2 /usr/lib/libpq.so.2.0 - libpq.so.2 /usr/lib/libpq.so.2.2 and PostgreSQL 7.3: /usr/lib/libpq.so - libpq.so.2.2 /usr/lib/libpq.so.2 - libpq.so.2.2 /usr/lib/libpq.so.2.0 - libpq.so.2 /usr/lib/libpq.so.2.2 the same. This would seem to imply binary compatibility? Lee. Tom Lane writes: Jeroen T. Vermeulen [EMAIL PROTECTED] writes: When receiving a trigger notification under 7.3, the structure returned by PQnotifies() appears to be bogus. In a test I ran, its be_pid was consistently zero and its relname pointed into never-neverland. We changed the PQnotifies result structure in 7.3 (to insulate clients from the value of NAMEDATALEN). I think you are compiling your app with a 7.3 libpq header and then running it with 7.2 libpq code, or possibly vice versa. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PQnotifies() in 7.3 broken?
Lee Kindness [EMAIL PROTECTED] writes: Perhaps the .so name should have been updated for PostgreSQL 7.3? It should have been. If it wasn't, that was a serious oversight. Not sure if we should change it in 7.3.1 or not, though; it may be too late for that. Any thoughts out there? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] setQuerySnapshot in plpgsql functions in 7.3
Forgive me for not digging through the source code myself, but can anyone tell me if setQuerySnapshot behavior within functions was changed in 7.3 so that subsequent select statements can see committed data? I know there was some talk about changing the behavior, but I'm wondering if it was ever done. Read committed transactions seem broken without this ability. Robert Treat ---(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] interesting difference for queries...
Rod Taylor [EMAIL PROTECTED] writes: cms=# CREATE TABLE foo(bar int); CREATE cms=# SELECT * from foo where bar=1.7; This is a numeric to integer coercion, which rounds No, it's an integer to numeric promotion (the var is promoted, not the constant). Obviously the '=' can never return true in this case. cms=# SELECT * from foo where bar='1.7'; ERROR: pg_atoi: error in 1.7: can't parse .7 This is a text to integer coercion, which doesn't round. And should not, IMHO. This is effectively the same as ... where bar = '1.7'::int which it seems to me is quite correct to throw a bad-input error. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] big text field - message type 0x44
Tom Lane [EMAIL PROTECTED] writes: Tomas Berndtsson [EMAIL PROTECTED] writes: Since it works in psql, it must be possible for my application to work too, but I just can't figure out why it doesn't. I think it's got to be a bug in your application code. A bug in libpq is the only other possibility --- but seeing that psql also uses libpq, I'm inclined to discount that. (You're sure you are linking the same version of libpq into your app that psql uses, right?) Yep, there is only one installation of PostgreSQL on the machine. My application is multithreaded, and I have been very careful to open a new connection for each thread. Could it have anything to do with semaphores and shared memory in Solaris? My /etc/system contains this: set shmsys:shminfo_shmmax=0x200 set shmsys:shminfo_shmmin=1 set shmsys:shminfo_shmmni=256 set shmsys:shminfo_shmseg=256 set semsys:seminfo_semmap=256 set semsys:seminfo_semmni=256 set semsys:seminfo_semmns=256 set semsys:seminfo_semmnu=256 set semsys:seminfo_semmsl=256 set semsys:seminfo_semopm=256 set semsys:seminfo_semume=256 set semsys:seminfo_semusz=256 I have these values to be able to have more connections than default to PostgreSQL. Maybe they need to be even higher? What's strange is that the same application and PostgreSQL version works fine in Linux. Tomas ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] interesting difference for queries...
On Wed, 2002-12-04 at 12:22, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: cms=# CREATE TABLE foo(bar int); CREATE cms=# SELECT * from foo where bar=1.7; This is a numeric to integer coercion, which rounds No, it's an integer to numeric promotion (the var is promoted, not the constant). Obviously the '=' can never return true in this case. Ahh, sorry. I see I changed the query slightly when doing the verbose explain. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
[HACKERS] postgres core dump
Just tried a make runcheck with source from Dec 4 15:13 GMT, and:
Core was generated by `postgres'.
Program terminated with signal 11, Segmentation fault.
#0 ExecGetTupType (node=0x8453978) at execProcnode.c:744
744 slot =
hashjoinstate-jstate.cs_ResultTupleSlot;
(gdb) bt
#0 ExecGetTupType (node=0x8453978) at execProcnode.c:744
#1 0x80e6f6e in InitPlan (operation=CMD_INSERT, parseTree=0x837bb68,
plan=0x8453978, estate=0x8453bc0) at execMain.c:585
#2 0x80e69a0 in ExecutorStart (queryDesc=0x8453b94, estate=0x8453bc0)
at execMain.c:124
#3 0x81404bc in ProcessQuery (parsetree=0x837bb68, plan=0x8453978,
dest=Debug, completionTag=0xbfbfb1a4 Ô±¿¿|à\023\bP³\\b\n)
at pquery.c:214
#4 0x813e6b1 in pg_exec_query_string (query_string=0x837b01c, dest=Debug,
parse_context=0x8367444) at postgres.c:838
#5 0x813f991 in PostgresMain (argc=9, argv=0x8266000,
username=0x8268120 prlw1) at postgres.c:2016
#6 0x80fb21f in main (argc=9, argv=0xbfbfb310) at main.c:234
#7 0x8069e84 in ___start ()
I think it had just got to the initdb..
(gdb) print *node
$1 = {type = T_HashJoin, startup_cost = 2.9253,
total_cost = 50.047, plan_rows = 370, plan_width = 172,
state = 0x8453bc0, instrument = 0x0, targetlist = 0x8453a4c, qual = 0x0,
lefttree = 0x8452874, righttree = 0x84538ec, extParam = 0x0, locParam = 0x0,
chgParam = 0x0, initPlan = 0x0, subPlan = 0x0, nParamExec = 0}
(gdb) print *node-hashjoinstate
There is no member named hashjoinstate.
??
Cheers,
Patrick
---(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] postgres core dump PS
(gdb) print *((HashJoin *) node)-hashjoinstate
$4 = {jstate = {type = T_HashJoinState, cs_OuterTupleSlot = 0x0,
cs_ResultTupleSlot = 0x84527cc, cs_ExprContext = 0x8453e60,
cs_ProjInfo = 0x84546e0, cs_TupFromTlist = 0 '\000'}, hj_HashTable = 0x0,
hj_CurBucketNo = 0, hj_CurTuple = 0x0, hj_OuterHashKeys = 0x8454728,
hj_InnerHashKeys = 0x84538d0, hj_OuterTupleSlot = 0x84527e0,
hj_HashTupleSlot = 0x8452790, hj_NullInnerTupleSlot = 0x0,
hj_NeedNewOuter = 1 '\001', hj_MatchedOuter = 0 '\000',
hj_hashdone = 0 '\000'}
of course.. but still, why the segfault?
Patrick
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
[HACKERS] postgres core FALSE ALARM
I must have had an old object file in the build tree... It's all happy now. Sorry for the noise, Patrick (geometry fails just because of the ordering of the rows in twenty) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [ADMIN] how to alter sequence.
Shridhar Daithankar kirjutas K, 04.12.2002 kell 20:51: On 4 Dec 2002 at 20:41, Hannu Krosing wrote: hannu=# update seq set max_value = 99; ERROR: You can't change sequence relation seq hannu=# update pg_class set relkind = 'r' where relname = 'seq'; UPDATE 1 hannu=# update seq set max_value = 99; UPDATE 1 hannu=# update pg_class set relkind = 'S' where relname = 'seq'; UPDATE 1 hannu=# select * from seq; sequence_name | last_value | increment_by | max_value | min_value | cache_value | log_cnt | is_cycled | is_called ---++--+---+---+-+-+---+--- seq | 1 |1 |99 | 1 | 1 | 1 | f | f I just discovered that changing these numbers does not change how the sequence behaves ;( Even after restarting the backend! Sorry! That makes me wonder. If sequense is treated like a single column single row table and it's value is guarenteed to be increasing even in case of aborted transaction, is it correct to say that postgresql already has nested transactions, albeit dormant? No. Sequences live outside of transactions. I have no idea why there is also a ingle column single row table created. The output of \d command is also weird, for all sequences I get: hannu=# \d seq Sequence public.seq Column | Type ---+- sequence_name | name last_value| bigint increment_by | bigint max_value | bigint min_value | bigint cache_value | bigint log_cnt | bigint is_cycled | boolean is_called | boolean with only the Sequence name changing ... --- Hannu ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] big text field - message type 0x44
Tomas Berndtsson [EMAIL PROTECTED] writes: Yep, there is only one installation of PostgreSQL on the machine. My application is multithreaded, and I have been very careful to open a new connection for each thread. Could it have anything to do with semaphores and shared memory in Solaris? I wouldn't think so; the client-side code doesn't have anything to do with either shared memory or semaphores. But your comment about threading immediately focuses my attention on that. Let's see (checks ASCII codes...) message 0x44 is 'D' which is a data message. The only situations I've seen before in which libpq comes out with this complaint are (1) when it's lost sync with the backend as a result of running out of memory to store a large query result (its recovery from that situation is pretty crummy :-(), or (2) when someone's confused libpq by trying concurrent queries with one PGconn. You say you didn't do (2), so that leaves (1). Is it possible that your threading setup limits the amount of memory libpq can malloc? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] big text field - message type 0x44
Tom Lane [EMAIL PROTECTED] writes:
Tomas Berndtsson [EMAIL PROTECTED] writes:
Yep, there is only one installation of PostgreSQL on the machine. My
application is multithreaded, and I have been very careful to open a
new connection for each thread. Could it have anything to do with
semaphores and shared memory in Solaris?
I wouldn't think so; the client-side code doesn't have anything to do
with either shared memory or semaphores. But your comment about
threading immediately focuses my attention on that.
Let's see (checks ASCII codes...) message 0x44 is 'D' which is a data
message. The only situations I've seen before in which libpq comes out
with this complaint are (1) when it's lost sync with the backend as a
result of running out of memory to store a large query result (its
recovery from that situation is pretty crummy :-(), or (2) when
someone's confused libpq by trying concurrent queries with one PGconn.
You say you didn't do (2), so that leaves (1). Is it possible that your
threading setup limits the amount of memory libpq can malloc?
I don't know what I would do to limit it. The machine has 2GB RAM, and
over 1GB free.
However, after some semi-random looking through the source code of
libpq, I tried to change a value, namely here:
fe-misc.c row 510 in pqReadData():
if (conn-inEnd 32768
(conn-inBufSize - conn-inEnd) = 8192)
{
someread = 1;
goto tryAgain;
}
I changed the 32768 value to 131072, and sure enough, my application
was able to get larger fields without any errors. The best thing would
of course be to have no limit to it. That would mean taking the whole
if-statement out, right? I've only tried with the value change,
though. There's a comment above this, saying it's a hack for some
kernels that only give back one packet, even if there is more. But, it
seems to confuse the Solaris kernel in some mysterious way when
running threads.
I haven't seen that it breaks anything else by changing this value,
but if you think it might, please tell me. I wouldn't want to risk
breaking other stuff.
Tomas
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] setQuerySnapshot in plpgsql functions in 7.3
Robert Treat [EMAIL PROTECTED] writes: Forgive me for not digging through the source code myself, but can anyone tell me if setQuerySnapshot behavior within functions was changed in 7.3 so that subsequent select statements can see committed data? AFAIR, we had some preliminary discussions about that, but no decision was taken about changing it. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] postgres core FALSE ALARM
Patrick Welche [EMAIL PROTECTED] writes: (geometry fails just because of the ordering of the rows in twenty) Yeah, that one's my fault. I will fix it soon. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] big text field - message type 0x44
Tomas Berndtsson [EMAIL PROTECTED] writes: However, after some semi-random looking through the source code of libpq, I tried to change a value, namely here: fe-misc.c row 510 in pqReadData(): if (conn-inEnd 32768 (conn-inBufSize - conn-inEnd) = 8192) I changed the 32768 value to 131072, and sure enough, my application was able to get larger fields without any errors. That's really interesting. I cannot see anything unsafe about that retry loop --- could you instrument it some more to determine exactly what happens after we go back to try to read more? Also, are you using SSL by any chance? Perhaps the problem is that the SSL library doesn't react the same as a bare recv() call? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] 24:00:00 ?
transatlantic=# select '23:59:59.72'::time(0) without time zone; time -- 24:00:00 (1 row) So dumping a table with times derived from the timestamp then fails on the reload with: psql:transatlantic.dat:43681: ERROR: copy: line 5818, Bad time external representation '24:00:00' psql:transatlantic.dat:43681: lost synchronization with server, resetting connection timeslice | timestamp(6) without time zone | timesliced | date | timeslicet | time(0) without time zone | (timesliced and timesllicet are for M$ Access' benefit and just contain the date and time parts of timeslice as per above) So, that's what happened, but what can one do? 24:00:00 seems like a sensible rounding for 23:59:59.72, and it is also true that 24:00:00 isn't really a valid time (or could it in strange days with an extra second?), so both sides seem to be right, it's just the overall effect which seems bad. (sed s/24:00:00/23:59:59/g fixed the 5.6Gb data file..) Cheers, Patrick ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [ADMIN] how to alter sequence.
On Wed, 2002-12-04 at 09:06, Oliver Elphick wrote: On Wed, 2002-12-04 at 12:29, raja kumar thatte wrote: Hai friends, I have a sequence called raj_seq with max value 3000. ... now i wanted to increase the max value of the raj_seq to 999. How to do this change? If i drop and recreate the raj_seq, then i have to recreate the table and all triggers working on that table.But it is not an acceptable solution. So with out droping raj_seq , how do I solve this problem. Unfortunately there doesn't seem to be any easy way to do this. There is no ALTER SEQUENCE command and you can't use UPDATE on a sequence. Hackers: Could this be a TODO item for 7.4? I'm hoping to do that one sooner than later, unless Neil beats me to it. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
Dave Page [EMAIL PROTECTED] writes: I'll preempt the 'this was all discussed on -advocacy, you should have been there' response with yet another agreement with Vince :-) - I too am getting far too much mail these days and another list is the last thing I need. I'm not subscribed to -advocacy either. I'm a little disturbed to hear that major decisions seem to be getting taken there without any mention in -hackers. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] nested transactions
[Sorry for the delay. I'm a bit busy these days.] On Fri, 29 Nov 2002 15:57:17 -0500 (EST), Bruce Momjian [EMAIL PROTECTED] wrote: BTW, I think this *forces* us to replace the sub xid with the respective main xid in a tuple header, when we set XMIN/MAX_IS_COMMITTED. Otherwise we'd have to look for the main xid, whenever a tuple is touched. Sorry, I don't follow this. Probably because we've mixed up several proposals. I'll try to pick them apart below. As far as I know, we will set the subxid on the tuple so we can independently mark the xact as aborted without revisiting all the tuples. Yes. Once it is committed/rolled back, These cases are completely different. If a (main or sub-) transaction is rolled back, its effects are invisible to all transactions; this status is immediately effective and final. OTOH a subtransaction commit is only tentative. It becomes effective when the main transaction commits. (And the subtransaction's status turns to aborted, when the main transaction aborts.) I see no need to lookup the parent, and in fact we could clear the clog parent xid offset so there is no way to access the parent anymore. While a subtransaction is seen as tentatively committed other transactions have to look up its parent to find out its effective status. Proposal A was: Never show tentatively committed to outside transactions. This would require neither any new flags in tuple headers or in pg_clog nor a globally visible pg_subtrans structure. But it only works, if we can commit a main transaction and all its subtransactions atomically, which is only possible if we hold a long lasting lock. Did we agree that we don't want this? All other solutions require a parent xid lookup at least during the time span while a subtransaction is marked tentatively committed and not yet known to be finally committed. IIRC we have three proposals how the tentatively committed status can be shown to outside transactions: (B) Two flags in the tuple header (one for xmin, one for xmax) telling us the xid is a subtransaction. I don't like this very much, because it's not in Normal Form: is a subtransaction is NOT a property of a tuple. OTOH we can declare it a denormalization for performance reasons (we don't have to look up the parend xid, if the flag is not set.) (C) Explicitly use the fourth possible status in pg_clog for tentatively committed. (Performance hack: replace with finally committed as soon as the xid is visible to all active transactions.) (D) Only one kind of committed in pg_clog; always look for a parent in pg_subtrans; for performance reasons integrate pg_subtrans into pc_clog. Tom brought up the snapshot visibility problem which applies to B, C, and D. While each of these proposals can be implemented (relatively) straight forward, the Black Art is: When and how can we modify the stored state to avoid repeated parent xid lookups? We'll find out ... Servus Manfred ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002, Vince Vielhaber wrote: That wasn't stronger, it was fluffier. It was full of buzzwords that were masking the actual content. Are you trying to hide the accomplishments or promote them? If you're trying to hide them like in this announcement you may want to try using this tool: http://www.dack.com/web/bullshit.html The stored phrases are much more refined and better paired. Bookmark'd for the next release ... thanks for the suggestion ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002, Vince Vielhaber wrote: I have a new design for it, now it's just getting the time to implement it. It's easy to add to and looks alot nicer. Cool, I think the only beef I ever had with it was the way the results were presented, but loved teh whole annotated aspects ... ---(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] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002, Tom Lane wrote: Dave Page [EMAIL PROTECTED] writes: I'll preempt the 'this was all discussed on -advocacy, you should have been there' response with yet another agreement with Vince :-) - I too am getting far too much mail these days and another list is the last thing I need. I'm not subscribed to -advocacy either. I'm a little disturbed to hear that major decisions seem to be getting taken there without any mention in -hackers. Everything that is discussed on -advocacy is generally that which is dealing with the advocacy web site ... case studies and such ... there are no major decisions being made over there ... in my case, it was a small pool of ppl interested in advocacy/marketing that I could draw on to write a stronger, less techie oriented, press release around ... I have a list of 350+ contacts that I used to get it out through, in various fields (university, publishing, etc) and needed something a little bit more at that level then I've been able to create in the past ... Most, if not all, of the stuff going through -advocacy is, right now, revolving around keeping track of the various press links that ppl find on the 'Net, which are to be added to the various sites that are currently being developed ... as well as a point of contact for liason'ng with companies willing/able to write and publish case studies ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
Marc G. Fournier wrote: On Wed, 4 Dec 2002, Vince Vielhaber wrote: That wasn't stronger, it was fluffier. It was full of buzzwords that were masking the actual content. Are you trying to hide the accomplishments or promote them? If you're trying to hide them like in this announcement you may want to try using this tool: http://www.dack.com/web/bullshit.html The stored phrases are much more refined and better paired. Bookmark'd for the next release ... thanks for the suggestion ... I was hoping for something that would take existing text and *Bullshit* it. Bummer. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Please, apply patch of tsearch for current CVS 7.3.1
Your patch has been added to the PostgreSQL unapplied patches list at: http://momjian.postgresql.org/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Teodor Sigaev wrote: Thank you very much, you catch it :). This bug had a long life, because it exists if and only if locale of postmaster was a different from C (or ru_RU.KOI8-R). Please, apply patch for current CVS 7.3.1 Magnus Naeslund(f) wrote: Ok, I nailed the bug, but i'm not sure what the correct fix is. Attached tsearch_morph.diff that remedies this problem by avoiding it. Also there's a debug aid patch if someone would like to know how i finally found it out :) There problem in the lemmatize() function is that GETDICT(...) returned a value not handled (BYLOCALE). The value (-1) and later used as an index into the dicts[] array. After that everything went berserk stack went crazy somehow so trapping the fault sent me to the wrong place, and every time i read the value it was positive ;) So now i just return the initial word passed to the lemmatize function, because i don't know what to do with it. So you tsearch guys will have to work it out :) -- Teodor Sigaev [EMAIL PROTECTED] [ application/gzip is not supported, skipping... ] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] 7.4 Wishlist
Christopher Kings-Lynne [EMAIL PROTECTED] wrote: Hi guys, Just out of interest, if someone was going to pay you to hack on Postgres for 6 months, what would you like to code for 7.4? Well, on top of the oft-requested replication support and savepoint support, I'd like to see UPDATE, er, updated to be able to make use of cursors. I'd also like to see (if this is even possible) a transaction isolation mode that would make it possible for multiple concurrent updates to the same row to happen without blocking each other (I imagine one way to make this possible would be for the last transaction to commit to be the one that wins. Each transaction that commits gets its updates written so that other transactions that begin after they commit will see them, of course). Neither read committed nor serialized modes offer this. Don't know if it's possible, but it would be nice (such that a transaction sees the database as if it has it all to itself and doesn't block on updates)... - Kevin ---(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] big text field - message type 0x44
Tom Lane [EMAIL PROTECTED] writes: Tomas Berndtsson [EMAIL PROTECTED] writes: However, after some semi-random looking through the source code of libpq, I tried to change a value, namely here: fe-misc.c row 510 in pqReadData(): if (conn-inEnd 32768 (conn-inBufSize - conn-inEnd) = 8192) I changed the 32768 value to 131072, and sure enough, my application was able to get larger fields without any errors. That's really interesting. I cannot see anything unsafe about that retry loop --- could you instrument it some more to determine exactly what happens after we go back to try to read more? Also, are you using SSL by any chance? Perhaps the problem is that the SSL library doesn't react the same as a bare recv() call? Nope, no SSL. I inserted some debug printing in the code. This is the output: LIBPQ: recv inbufsize=16384 inend=0 nread=8192 LIBPQ: recv inbufsize=16384 inend=6194 nread=8192 LIBPQ: recv inbufsize=32768 inend=14386 nread=8192 LIBPQ: recv inbufsize=32768 inend=22578 nread=8192 LIBPQ: recv inbufsize=65536 inend=30770 nread=8192 LIBPQ: trying again LIBPQ: recv inbufsize=65536 inend=38962 nread=-1 LIBPQ: SOCK_ERRNO = 25 (Inappropriate ioctl for device) message type 0x44 arrived from server while idle The recv row is printed right after recv is called. trying again is printed inside the if (conn-inEnd 32768 (conn-inBufSize - conn-inEnd) = 8192) After it tries again, it always gets error from recv() for some reason that I don't know. I also don't understand why errno is set to ENOTTY at this point, that makes no sense at all. But it does, and libpq doesn't recognise the errno code and therefore returns -1 from pqReadData(). By skipping the trying again if-statement, pqReadData() will always return proper data, and let the calling function deal with the fact that there is more data to be read. I don't know if I can help you more than this. I have absolutely no idea why recv() would fail with ENOTTY. Tomas ---(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] big text field - message type 0x44
Tomas Berndtsson [EMAIL PROTECTED] writes: After it tries again, it always gets error from recv() for some reason that I don't know. I also don't understand why errno is set to ENOTTY at this point, that makes no sense at all. Are you sure it is set? Try setting errno=0 just before recv() (inside the retry loop). Maybe recv() is neglecting to set it in this case. I suddenly have a recollection of something about some platform failing to set errno when using threads. Try searching the PG archives. By skipping the trying again if-statement, pqReadData() will always return proper data, and let the calling function deal with the fact that there is more data to be read. I have no confidence in this. If the calling function comes back for more data, why wouldn't the recv() fail the same way? A few more instructions in between shouldn't change its behavior, one would think. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002, Bruce Momjian wrote: Marc G. Fournier wrote: On Wed, 4 Dec 2002, Vince Vielhaber wrote: That wasn't stronger, it was fluffier. It was full of buzzwords that were masking the actual content. Are you trying to hide the accomplishments or promote them? If you're trying to hide them like in this announcement you may want to try using this tool: http://www.dack.com/web/bullshit.html The stored phrases are much more refined and better paired. Bookmark'd for the next release ... thanks for the suggestion ... I was hoping for something that would take existing text and *Bullshit* it. Bummer. Click on it a few times. You'll get the text you need. I've actually used it for real things with excellent results (I'm not going to elaborate). Vince. -- http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PQnotifies() in 7.3 broken?
Tom Lane wrote: Lee Kindness [EMAIL PROTECTED] writes: Perhaps the .so name should have been updated for PostgreSQL 7.3? It should have been. If it wasn't, that was a serious oversight. Not sure if we should change it in 7.3.1 or not, though; it may be too late for that. Any thoughts out there? Seems I did forget. I always update the minor for a major release, but when development starts, and I seem to have forgotten for 7.3. Sorry. I will update for 7.4 now. Too late for 7.3 clearly. Turns out I usually do it when I stamp the new development tree, but someone else stamped 7.3 and 7.4. :-( Here is 7.2 stamp, which shows the updates: revision 1.52 date: 2001/05/11 01:46:33; author: momjian; state: Exp; lines: +2 -2 Stamp CVS as 7.2. Update all interface version numbers. This is the time to do it, not during beta because people are using this stuff in production sometimes. The diff shows: *** *** 15,21 # shared library parameters NAME= pq SO_MAJOR_VERSION= 2 ! SO_MINOR_VERSION= 1 override CPPFLAGS := -I$(srcdir) $(CPPFLAGS) -DFRONTEND -DSYSCONFDIR='$(sysco nfdir)' --- 15,21 # shared library parameters NAME= pq SO_MAJOR_VERSION= 2 ! SO_MINOR_VERSION= 2 so clearly 7.2 and 7.3 have the same minor version for all interfaces. Bad! -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] v7.3 planner and user-defined functions
I sent this message to pgsql-performance yesterday, but as of now (about 30
hours later) I haven't yet received a response. So I figured I'd see what
you guys think. Please help if you can. Thanks!
==
I am having some problems with user-defined functions in version 7.3. The
planner seems to refuse to use an index that I have created when I define an
SQL function that should take advantage of it. The thing that is driving me
nuts is that if I take the SQL from the function definition and run it
exactly as it is, replacing the parameters with real values, then it does
use the index and performs beautifully. I never saw this problem until I
upgraded from 7.2.3 to 7.3.
At the bottom of this email, I have included a psql test input file and the
results. I have an index on zip_locs(dist1,dist2,dist3,dist4). I'm joining
a table of about 350,000 rows (mytable) against another table of about
42,000 rows (zip_locs) on a ZIP code. The ZIP fields in both tables are
indexed as well. The functions zip_dist[1234](varchar) return the
respective dist[1234] value for the given ZIP code. The zip_lat(varchar)
and zip_lng(varchar) functions return the latitude and longitude for the
given ZIP code, respectively. All these functions are immutable so they
have virtually no effect on the speed of the query. The point of the query
is to get a count of records in mytable that are within a certain distance
of a given ZIP code.
When I do the explicit SELECT, it uses the aforementioned index and then
filters on the result of the earth_distance(real,real,real,real) function.
When I run the radiuscount(varchar,real) function, it apparently does a
sequential scan instead of using the index.
I have tried rewriting this query every way I know how, but nothing seems to
work. Can anybody help me with this?
Here is the psql input file I'm using to demonstrate:
***
CREATE OR REPLACE FUNCTION radiuscount(varchar, real) RETURNS bigint AS
'
SELECT COUNT(*)
FROM mytable JOIN zip_locs ON zip = zip_code
WHERE
dist1 BETWEEN zip_dist1($1) - $2::real AND zip_dist1($1) +
$2::real
AND dist2 BETWEEN zip_dist2($1) - $2::real AND zip_dist2($1) +
$2::real
AND dist3 BETWEEN zip_dist3($1) - $2::real AND zip_dist3($1) +
$2::real
AND dist4 BETWEEN zip_dist4($1) - $2::real AND zip_dist4($1) +
$2::real
AND earth_distance(zip_lat($1), zip_lng($1), lat, lng) $2::real
' LANGUAGE 'SQL'
STABLE
RETURNS NULL ON NULL INPUT
;
\timing
\a
\t
\echo
\echo 'NOT using the function'
SELECT COUNT(*) AS radiuscount
FROM mytable JOIN zip_locs ON zip = zip_code
WHERE
dist1 BETWEEN zip_dist1('30096') - 20::real AND
zip_dist1('30096') + 20::real
AND dist2 BETWEEN zip_dist2('30096') - 20::real AND
zip_dist2('30096') + 20::real
AND dist3 BETWEEN zip_dist3('30096') - 20::real AND
zip_dist3('30096') + 20::real
AND dist4 BETWEEN zip_dist4('30096') - 20::real AND
zip_dist4('30096') + 20::real
AND earth_distance(zip_lat('30096'), zip_lng('30096'), lat, lng)
20::real
;
\echo
\echo 'Using the function'
select radiuscount('30096',20);
***
And here is the output:
***
CREATE FUNCTION
Timing is on.
Output format is unaligned.
Showing only tuples.
NOT using the function
2775
Time: 584.02 ms
Using the function
2775
Time: 11693.56 ms
***
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] nested transactions
Manfred Koizar wrote: [Sorry for the delay. I'm a bit busy these days.] On Fri, 29 Nov 2002 15:57:17 -0500 (EST), Bruce Momjian [EMAIL PROTECTED] wrote: BTW, I think this *forces* us to replace the sub xid with the respective main xid in a tuple header, when we set XMIN/MAX_IS_COMMITTED. Otherwise we'd have to look for the main xid, whenever a tuple is touched. Sorry, I don't follow this. Probably because we've mixed up several proposals. I'll try to pick them apart below. OK. These cases are completely different. If a (main or sub-) transaction is rolled back, its effects are invisible to all transactions; this status is immediately effective and final. OTOH a subtransaction commit is only tentative. It becomes effective when the main transaction commits. (And the subtransaction's status turns to aborted, when the main transaction aborts.) Right. I see no need to lookup the parent, and in fact we could clear the clog parent xid offset so there is no way to access the parent anymore. While a subtransaction is seen as tentatively committed other transactions have to look up its parent to find out its effective status. Right. And we need those lookups to parent from the start of the subtransaction until the commit/abort of the main transaction. If it aborts, we can shorten that, but if they are all commit, we have to wait, and they have to be visible because other backends have to know if the Running status of the transaction is still associated with an active transaction, and we can only stamp one xid on a backend because shared memory is limited. Proposal A was: Never show tentatively committed to outside transactions. This would require neither any new flags in tuple headers or in pg_clog nor a globally visible pg_subtrans structure. But it only works, if we can commit a main transaction and all its subtransactions atomically, which is only possible if we hold a long lasting lock. Did we agree that we don't want this? Again, we still need the lookup to main transaction for other backend lookups, so this idea is dead, and we don't want locking. All other solutions require a parent xid lookup at least during the time span while a subtransaction is marked tentatively committed and not yet known to be finally committed. IIRC we have three proposals how the tentatively committed status can be shown to outside transactions: Yes. (B) Two flags in the tuple header (one for xmin, one for xmax) telling us the xid is a subtransaction. I don't like this very much, because it's not in Normal Form: is a subtransaction is NOT a property of a tuple. OTOH we can declare it a denormalization for performance reasons (we don't have to look up the parend xid, if the flag is not set.) I see no reason to do that when we have that 4th state available in pg_clog. They are going to lookup the xid status anyway, so why not check that is subtransaction status at that point too. Of course, we can't mark IS COMMITTED on the tuple until the main transaction commits, but that is simple logic. (C) Explicitly use the fourth possible status in pg_clog for tentatively committed. (Performance hack: replace with finally committed as soon as the xid is visible to all active transactions.) Yes, I think this is the only way to go. If we need that 4th state later, we can refactor the code, but for our purposes now, it is useful. (D) Only one kind of committed in pg_clog; always look for a parent in pg_subtrans; for performance reasons integrate pg_subtrans into pc_clog. Seems that 4th state makes this an easy optimization, causing zero overhead for backends that _don't_ use subtransactions, except for backends looking up the status of other backends with subtransactions. Tom brought up the snapshot visibility problem which applies to B, C, and D. While each of these proposals can be implemented (relatively) straight forward, the Black Art is: When and how can we modify the stored state to avoid repeated parent xid lookups? We'll find out ... I think there is now general agreement that we want a separate table to store parent xids for subtransactions that is only looked up when that 4th clog state is set, and once the main transaction commits, all those 4th state clog entries can be cleaned up to simple commit. We can also expire the pg_subtrans table for any xids less than the lowest running backend xid, which is pretty significant optimization. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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] [GENERAL] PostgreSQL Global Development Group Announces
It isn't, but those working on -advocacy were asked to help come up with a stronger release *announcement* then we've had in the past ... Consider that a failed experiment. PostgreSQL is driven by the development group and, to some extent, by the existing user base. The last thing we need is a marketing department in that mix. Ummm...I disagree. Lack of marketing is one of Postgres's major problems. Particularly when you compare against similar efforts from MySQL, Oracle, etc. Yes, indeed. The _prime_ reason for the fact that MySQL is the M in LAMP is that there is a steady, intent set of efforts going into marketing the M. People think that MySQL is faster, easier to use and more standard than its alternatives, and that is certainly the result of marketing. The /real/ technical merit of MySQL has been that there are some integrated tools for ISPs like CPANEL that make it easy for ISPs that don't know /anything/ about DBMSes to provide MySQL for their customers. CPANEL doesn't support PostgreSQL, and historically, it has been somewhat more difficult to support large numbers of PostgreSQL instances on a web server. Some of that has changed, though CPANEL /still/ doesn't support PostgreSQL. If any of you consider these technical issues to be small and petty, I'm afraid I don't /care/. More importantly, the hundreds of ISPs licensing CPANEL don't care. /They/ are the ones that would need convincing, and I don't think there's any real route to convince them that they should be pounding down CPANEL's door asking for a PostgreSQL front end and to convince them that they have to tell their customers: We sold you MySQL, telling you it was good for you to use. We were wrong, and our new story is that you should convert your databases over to use PostgreSQL. Anyone consider that a likely scenario? Anyone? It's fair to say that PostgreSQL doesn't need the likes of the Database HOWTO that gives a sales job that's so blindly enthusiastic as to be, well, blind. But an organization that has /no/ marketing department is at a severe disadvantage, like it or not. It is unfortunate that it is almost impossible to have a marketing group without there being some wilful blinders involved; it's vital for there to be some technical involvement in the marketing group to pop whatever bubbles they grow that are woefully wrong. But even if it operates with some occasional lack of /real/ vision, it's necessary to have a marketing group... -- (reverse (concatenate 'string moc.enworbbc@ sirhc)) http://cbbrowne.com/info/advocacy.html Rules of the Evil Overlord #106. If my supreme command center comes under attack, I will immediately flee to safety in my prepared escape pod and direct the defenses from there. I will not wait until the troops break into my inner sanctum to attempt this. http://www.eviloverlord.com/ ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
[cc: list trimmed] On Wednesday 04 December 2002 22:52, Philip Warner wrote: At 05:48 PM 4/12/2002 -0800, Christopher Kings-Lynne wrote: Lack of marketing is one of Postgres's major problems. What are the consequences of the problem? Actually, lack of easy upgrading is one of PostgreSQL's major problems But lack of focused marketing -- truthful, not, as has been said, like the 'Database HOWTO' -- is a real problem. It would be nice to increase our usage. If that is what we want, then fine. But I don't want to see any part of the development effort distorted or the existing user base inconvenienced in an effort to purely gain that market share. I usually associate increased marketing with decreased quality, and I think the causality works *both* ways. ISTM there's a separate, non-code-developer group doing this. It doesn't seem to take away _any_ developer resources to do an advocacy site. However, I seriously question the need in the long term for our sites to be as fractured as they are. Good grief! We've got advocacy.postgresql.org, techdocs.postgresql.org, odbc.postgresql.org, gborg.postgresql.org, developer.postgresql.org, jdbc.postgresql.org, etc. Oh, and we also have www.postgresql.org on the side? I think not. Oh, and they are fractured in their styles -- really, guys, we need a unified style here. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] unofficial 7.3 RPMs
Hannu Krosing wrote: Except that I had to tweak the startup script - as distributed it defines the version to be 7.3b2 and checks database for version 7.2. It also expects/puts the database in nonstandard place. Oops! That's why it is the unofficial RPM set ;-) FWIW, I produced a new set that should fix these two issues and those are now posted in place of the others. http://www.joeconway.com/ Thanks, Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Wed, 4 Dec 2002, Bruce Momjian wrote: Marc G. Fournier wrote: On Wed, 4 Dec 2002, Vince Vielhaber wrote: That wasn't stronger, it was fluffier. It was full of buzzwords that were masking the actual content. Are you trying to hide the accomplishments or promote them? If you're trying to hide them like in this announcement you may want to try using this tool: http://www.dack.com/web/bullshit.html The stored phrases are much more refined and better paired. Bookmark'd for the next release ... thanks for the suggestion ... I was hoping for something that would take existing text and *Bullshit* it. Bummer. No, but I figure that at least it will give me a good site to give me BS fodder from ... man, just wait for the next release announcement :) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PQnotifies() in 7.3 broken?
Bruce Momjian writes: so clearly 7.2 and 7.3 have the same minor version for all interfaces. Bad! We forgot between 7.0 and 7.1 as well, so it's at least consistent... -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
Marc G. Fournier writes: It isn't, but those working on -advocacy were asked to help come up with a stronger release *announcement* then we've had in the past ... Consider that a failed experiment. PostgreSQL is driven by the development group and, to some extent, by the existing user base. The last thing we need is a marketing department in that mix. -- Peter Eisentraut [EMAIL PROTECTED] ---(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] [GENERAL] PostgreSQL Global Development Group Announces
Peter Eisentraut wrote: Marc G. Fournier writes: It isn't, but those working on -advocacy were asked to help come up with a stronger release *announcement* then we've had in the past ... Consider that a failed experiment. PostgreSQL is driven by the development group and, to some extent, by the existing user base. The last thing we need is a marketing department in that mix. Peter, I understand your perspective, but I think you are in the minority on this one. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PQnotifies() in 7.3 broken?
Peter Eisentraut wrote: Bruce Momjian writes: so clearly 7.2 and 7.3 have the same minor version for all interfaces. Bad! We forgot between 7.0 and 7.1 as well, so it's at least consistent... Yes, seems we increament on every even-numbered release. ;-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(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] PQnotifies() in 7.3 broken?
On Wed, 2002-12-04 at 13:11, Bruce Momjian wrote: Seems I did forget. I always update the minor for a major release, but when development starts, and I seem to have forgotten for 7.3. Sorry. I will update for 7.4 now. Too late for 7.3 clearly. Wouldn't that suggest that libpq in 7.4 and 7.3 are *not* binary compatible? AFAIK that's not the case... Cheers, Neil -- Neil Conway [EMAIL PROTECTED] || PGP Key ID: DB3C29FC ---(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] big text field - message type 0x44
Tom Lane wrote: Tomas Berndtsson [EMAIL PROTECTED] writes: After it tries again, it always gets error from recv() for some reason that I don't know. I also don't understand why errno is set to ENOTTY at this point, that makes no sense at all. Are you sure it is set? Try setting errno=0 just before recv() (inside the retry loop). Maybe recv() is neglecting to set it in this case. I suddenly have a recollection of something about some platform failing to set errno when using threads. Try searching the PG archives. I don't know whether or not things have changed significantly since Solaris 2.4 (and perhaps 2.5), but I seem to remember that back then a lot of the networking code was implemented in libraries on top of SVr4 TLI (Transport Layer Interface), and thus functions like recv() that made use of internet domain sockets were actually just wrappers around the TLI stuff. If it's still implemented that way, I suppose there's the possibility that recv() isn't thread-safe under Solaris, but I doubt it. Such a deficiency would be quite glaring considering what threads are used for. Just food for thought, for what it's worth... - Kevin ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Wed, 04 Dec 2002 22:54:37 -0500, Philip Warner wrote: At 05:48 PM 4/12/2002 -0800, Christopher Kings-Lynne wrote: Lack of marketing is one of Postgres's major problems. What are the consequences of the problem? One consequence that probably hits home for everyone here is it makes it extremely hard to make a living working with postgresql. A quick search on monster.com gives me 17 jobs mentioning postgresql, with none listed in the last week. A search on mysql gives me 100 jobs, with 3 filed just today. I won't even go into the numbers for Oracle, DB2, and M$. We all have to pay the bills and I think we'd like to do it working with postgresql. Particularly when you compare against similar efforts from MySQL, Oracle, etc. You could even include Microsoft here - they do a lot of database marketing. I am not at all sure the fact that a lot of large companies with dubious products engage in extensive marketing is a reason for *us* to engage in extensive marketing. You can't win marketshare on technology alone, so unless you think we don't need to increase our market share, that is reason enough to do more marketing. We already have a substantial following, and our clients have direct access to the developers, so any marketing group is pretty irrelevant for existing clients. So the only place I can see for a marketing group is in building our market share by bringing in new clients. Well, my previous employer uses postgresql, but they were under constant assault from their clients to use oracle or db2. Technically there was no reason to switch, but if your choice is switch databases or go out of business, there really isn't much choice. In the company I work for now we use at least 4 different database systems. We could probably switch all of these to postgresql, but it probably be one heck of a battle to convince people of that. A simple argument that could be raised is that several of the database developers use ERWin from computer associates. ERWin's postgresql support is spotty compared to its support of oracle, and unless there is a groundswell of demand for better postgresql support, that's not going to change. If postgresql can gain a larger market share, computer associates might improve their postgresql support, and we, existing clients that we are, will be able to use postgresql in more areas. Marketing is very relevant to existing customers. If that is what we want, then fine. But I don't want to see any part of the development effort distorted or the existing user base inconvenienced in an effort to purely gain that market share. I usually associate increased marketing with decreased quality, and I think the causality works *both* ways. Aren't most development efforts made simply to gain market share? After all, I don't think we added schema support to get *less* people to use postgresql. Robert Treat ---(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] about one query.
if I create a table like this create table test (nuber int4,id_num int4,primary key(id_num)); My question is, ¿ I can do this ? insert into test (number) values (10); insert into test (number) values (22); insert into test (number) values (3); and make a function to insert the correct id_num in this table ? some one have or try to do this ? Thanks for all. -- Saludos Horacio Miranda. [EMAIL PROTECTED] PostgreSQL. Because life's too short to learn Oracle.:) Billy O'Connor IBM -- Immer Backup Machen ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
It isn't, but those working on -advocacy were asked to help come up with a stronger release *announcement* then we've had in the past ... Consider that a failed experiment. PostgreSQL is driven by the development group and, to some extent, by the existing user base. The last thing we need is a marketing department in that mix. Ummm...I disagree. Lack of marketing is one of Postgres's major problems. Particularly when you compare against similar efforts from MySQL, Oracle, etc. Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
At 05:48 PM 4/12/2002 -0800, Christopher Kings-Lynne wrote: Lack of marketing is one of Postgres's major problems. What are the consequences of the problem? Particularly when you compare against similar efforts from MySQL, Oracle, etc. You could even include Microsoft here - they do a lot of database marketing. I am not at all sure the fact that a lot of large companies with dubious products engage in extensive marketing is a reason for *us* to engage in extensive marketing. We already have a substantial following, and our clients have direct access to the developers, so any marketing group is pretty irrelevant for existing clients. So the only place I can see for a marketing group is in building our market share by bringing in new clients. If that is what we want, then fine. But I don't want to see any part of the development effort distorted or the existing user base inconvenienced in an effort to purely gain that market share. I usually associate increased marketing with decreased quality, and I think the causality works *both* ways. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] [GENERAL] PostgreSQL Global Development Group
Robert Treat wrote: On Wed, 04 Dec 2002 22:54:37 -0500, Philip Warner wrote: At 05:48 PM 4/12/2002 -0800, Christopher Kings-Lynne wrote: Lack of marketing is one of Postgres's major problems. What are the consequences of the problem? One consequence that probably hits home for everyone here is it makes it extremely hard to make a living working with postgresql. A quick search on monster.com gives me 17 jobs mentioning postgresql, with none listed in the last week. A search on mysql gives me 100 jobs, with 3 filed just today. I won't even go into the numbers for Oracle, DB2, and M$. We all have to pay the bills and I think we'd like to do it working with postgresql. One other thing marketing does is attracting developers, including _paid_ developers, to work on PostgreSQL. Fortunately PostgreSQL is a big hit in Japan, so SRA can pay me to work on PostgreSQL. If we can increase PostgreSQL's popularity, we will get more people working to improve PostgreSQL, both paid and volunteers. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Lamar Owen wrote: However, I seriously question the need in the long term for our sites to be as fractured as they are. Good grief! We've got advocacy.postgresql.org, techdocs.postgresql.org, odbc.postgresql.org, gborg.postgresql.org, developer.postgresql.org, jdbc.postgresql.org, etc. Oh, and we also have www.postgresql.org on the side? I think not. Oh, and they are fractured in their styles -- really, guys, we need a unified style here. I'd love to see this happen. From reading the messages here, it sounds like the perception is that marketing == spouting bullshit. I don't believe that's true. I think having an informative, up-to-date, stylistically consistent website would do a tremendous amount of good. The JDBC one is a particularly bad example right now - it doesn't fit in with any of the rest of the site and its most prominent link is to a completely out-of-date list of compliance tests the driver fails. The driver may have its flaws but it's a lot better than presented there. IMHO these things make a difference to technical people as well as suits. If that site and the MySQL JDBC driver's site were my first impressions, I would be using MySQL. The JDBC site is certainly not the only one with flaws. The main website has this paragraph in http://www15.us.postgresql.org/related.html: For encrypted postgresql connections, Brett McCormick ([EMAIL PROTECTED]) has made a patch for PostgreSQL version 6.3.2 using SSL. Visit his info page for more information. That's horribly obselete. In fact, I think a lot of the related projects are. That's only two clicks away from the main page. I'm volunteering to do work here. I could at the very least go through the sites and make a longer list of things like this that I notice. If they are public CVS somewhere, I can send patches. I saw that there's a http://wwwdevel.postgresql.org/. What's going on with that? Is there anything I can do to speed up its adoption? How will it affect the rest of the sites? Is this list the appropriate place to discuss the websites? or should I take it to -advocacy? My impression here is that the two sites are maintained separately and the people involved haven't interacted very much. Is that accurate or no? Thanks, Scott ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] dbmirror
Yes, I get the same failure. with perl 5.005_03. Steven, can you comment on this? --- Tatsuo Ishii wrote: Hi, I have been playing around with contrib/dbmirror with RC2 and faced with following errors: perl DBMirror.pl slaveDatabase.conf Global symbol $setResult requires explicit package name at DBMirror.pl line 131. Global symbol $setResult requires explicit package name at DBMirror.pl line 132. Global symbol $setResult2 requires explicit package name at DBMirror.pl line 140. Global symbol $setResult2 requires explicit package name at DBMirror.pl line 141. Execution of DBMirror.pl aborted due to compilation errors. This Linux and perl 5.6.1. -- Tatsuo Ishii ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Thu, 5 Dec 2002, Philip Warner wrote: What are the consequences of the problem? Speaking from the perspective of a long time postgresql user, who currently has several very mission critical applications using postgresql on the back end, at a very large company... I can say the one consequence of the problem that I have run into personally, is convincing management to allow me to use postgresql for my projects to begin with. Fortunately, where I am currently employed, I was able to bash my head against the brick wall until they got tired of hearing from me, and allowed me to go with postgresql instead of sybase (which was their first choice, as the corporation already has a sybase site license). The lack of name recognition was a factor that contributed to the difficulty of getting postgresql accepted. The last thing a non technical middle manager wants to tell his or her manager is that some mission critical application that just crashed was running on some database he had never heard of before that he gave the go ahead to use. Anyway, this probably doesn't belong on this mailing list, but I saw the question and figured I'd answer :) By the way, I'm happy to report that after a year of absolutely flawless performance ( except the day the raid array imploded, which was hardly postgres's fault ), postgresql has a very good reputation in my department. Brian Knox Systems Programmer ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] 7.3 RPMS.
I have built and am uploading RPMS for 7.3. Mirror propagation being what it is, it may take a day or two for these packages to make the rounds. You may find them at: ftp://ftp.postgresql.org/pub/binary/v7.3/RPMS Source RPM in SRPMS, Red Hat 8 RPMS in redhat-8.0. I will be building Red Hat 7.3 RPMs soon. Many thanks to Joe Conway for lighting the fire under me (by releasing unofficial RPMs -- that's a good sign 'you're late Lamar!'); as well as 'thanks' for this ice storm that kept me home today to do this. :-) (otherwise, I had (have) a deskful of Real Work piled up.) The source RPM is up; the binaries are on their way as I hit send. There are significant changes in this RPM from previous releases. Most significantly there is experimental support for multiple postmasters, courtesy Karl DeBisschop. Next most significantly, upgrading the server subpackage from a previous major version IS NOT SUPPORTED. AT ALL. If an rpm -U works for you without you going through odd RPM measures for postgresql-server-7.3-1PGDG.i386.rpm, then I've made an error somewhere, because the upgrade lock worked here :-). Upgrading must be done by dumping the old database out, rpm -e the old server subpackage, install the new server subpackage, start the new postmaster (initdb is automatic on first start when using the supplied initscript), and restore your data. Upgrading the remainder of the subpackages IS supported -- you may upgrade everything but the server subpackage, migrate your data, and do the dump/restore dance. Also, due to the client-side splitout in CVS and the tarball, there have been significant changes to the packaging. Most notably, there is no more postgresql-perl subpackage. Nor is there a postgresql-odbc, or postgresql-tk (which really was primarily pgaccess, which is separate now -- and the pgtksh client is now rolled into the postgresql-tcl package IF the tk client was built at rpmbuild time). The libpq++ and libpgeasy libraries are gone -- everything that used to be in the main tarball but isn't anymore, basically, is gone from this RPM set. Oddly enough you will need the Pg module installed for some of the contrib code to actually work. With separate builds will come separate RPMS -- which I may or may not maintain.anyone who wishes to may for those clients. To whomever inherits the Pg build kludgage I bequeath the building section of the 7.2.3 RPMset's spec file -- good luck (and good riddance to the kludgage). The non-plpgsql procedural languages share a subpackage called postgresql-pl -- that is, if they were built. Switches internal to the rpm sepc file control the individual pieces that are built -- Red Hat 8.0 will build all three PL's just fine, but Red Hat 7.3 won't build plperl in its default incarnation. So there is no more postgresql-plperl subpackage. There are additions to the contrib package, as well as migrations from the contrib package to the server package -- pg_resetxlog and pg_controldata in particular. The contrib files are installed in the expected places -- executables in /usr/bin, libraries in /usr/lib/pgsql. Regression passes (on Red Hat 8.0) on all but select_having, which fails due to collation sequence issues (with the tests run in the installed binary environment, not as 'make installcheck'). Other changes may be forthcoming depending upon user feedback. :-) (that is, if you complain enough about something I can deal with in the packaging, then you might get your wish -- just don't complain to me about the lack of upgrading support -- that part is not my fault.) In particular, if you are the package maintainer in charge of PostgreSQL for a Linux distribution, I really want to hear from you. (I have heard from two). The postgresql-python subpackage requires the 'mx' extensions to be installed in order to work -- but not build! Red Hat 7.3 and up include the mx package. The README.rpm-dist file has been updated to reflect these packaging changes. One BIG note: if you miss '-i' on the postmaster options, you need to take a look at /var/lib/pgsql/data/postgresql.conf, and study the 'tcpip_sockets' parameter. Do NOT edit the initscript -- it will be overwritten during the next upgrade. Rebuilding from the source RPM is detailed in README.rpm-dist (with a minor typo). The typo is 'use rpm -ba' -- which doesn't work on any distribution with RPM 4.1 installed (such as Red Hat 8). You will need to use 'rpmbuild -ba' or 'rpmbuild --rebuild' instead -- which also will work on RPM 4.0.x boxen. The recent entries in the CHANGELOG for the spec file are as follows (it refers to 7.3-0.5PGDG, and should have read 7.3-1PGDG, but the source RPM was already uploaded before I caught it -- and at 33.6 dialup (that's bouncing up and down like a yoyo due to periodic telephone service interruptions) a 10MB file takes a little time to upload (as in a couple of hours or more), and it's an
Re: [HACKERS] contrib/ltree patches
Dan, is this ready to be applied to CVS?
---
Dan Langille wrote:
I have been looking at contrib/ltree in the PostgreSQL repository. I've
modified the code to allow / as a node delimiter instead of . which is the
default.
Below are the patches to make this change. I have also moved the
delimiter to a DEFINE so that other customizations are easily done. This
is a work in progress.
My thanks to DarbyD for assistance.
cheers
--- ltree.h.orig Tue Nov 26 18:57:58 2002
+++ ltree.h Tue Nov 26 20:16:40 2002
@@ -6,6 +6,8 @@
#include utils/palloc.h
#include utils/builtins.h
+#define NODE_DELIMITER '/'
+
typedef struct
{
uint8 len;
@@ -88,7 +90,7 @@
#ifndef abs
#define abs(a) ((a) (0) ? -(a) : (a))
#endif
-#define ISALNUM(x) ( isalnum((unsigned int)(x)) || (x) == '_' )
+#define ISALNUM(x) ( isalnum((unsigned int)(x)) || (x) == '_' || (x) ==
NODE_DELIMITER )
/* full text query */
--- ltree_io.cTue Nov 26 20:23:45 2002
+++ ltree_io.c.orig Tue Nov 26 18:57:26 2002
@@ -48,7 +48,7 @@
ptr = buf;
while (*ptr)
{
- if (*ptr == NODE_DELIMITER)
+ if (*ptr == '.')
num++;
ptr++;
}
@@ -69,7 +69,7 @@
}
else if (state == LTPRS_WAITDELIM)
{
- if (*ptr == NODE_DELIMITER)
+ if (*ptr == '.')
{
lptr-len = ptr - lptr-start;
if (lptr-len 255)
@@ -131,7 +131,7 @@
{
if (i != 0)
{
- *ptr = NODE_DELIMITER;
+ *ptr = '.';
ptr++;
}
memcpy(ptr, curlevel-name, curlevel-len);
@@ -181,7 +181,7 @@
ptr = buf;
while (*ptr)
{
- if (*ptr == NODE_DELIMITER)
+ if (*ptr == '.')
num++;
else if (*ptr == '|')
numOR++;
@@ -265,7 +265,7 @@
lptr-len, (int) (lptr-start - buf));
state = LQPRS_WAITVAR;
}
- else if (*ptr == NODE_DELIMITER)
+ else if (*ptr == '.')
{
lptr-len = ptr - lptr-start -
((lptr-flag LVAR_SUBLEXEM) ? 1 : 0) -
@@ -289,7 +289,7 @@
{
if (*ptr == '{')
state = LQPRS_WAITFNUM;
- else if (*ptr == NODE_DELIMITER)
+ else if (*ptr == '.')
{
curqlevel-low = 0;
curqlevel-high = 0x;
@@ -347,7 +347,7 @@
}
else if (state == LQPRS_WAITEND)
{
- if (*ptr == NODE_DELIMITER)
+ if (*ptr == '.')
{
state = LQPRS_WAITLEVEL;
curqlevel = NEXTLEV(curqlevel);
@@ -471,7 +471,7 @@
{
if (i != 0)
{
- *ptr = NODE_DELIMITER;
+ *ptr = '.';
ptr++;
}
if (curqlevel-numvar)
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(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] Compiere embedded transactions
I am not sure you are going to be happy with our nested transactions. Your text is: (1) embedded transactions - i.e. the outer transaction can rollback an inner committed transaction - currently the commit of the inner transaction would commit statements of the inner and outer transaction. Are you saying: BEGIN; ... BEGIN; UPDATE ... COMMIT or ABORT; ... COMMIT; that you want the UPDATE to commit even if the outer transaction aborts? I don't plan to have nested transactions work that way. What will happen is that if the UPDATE transaction aborts, the outer transaction will not automatically abort. Will that help you? The savepoint version is: BEGIN; ... SAVVEPOINT xx; UPDATE ... ROLLBACK TO xx; ... COMMIT; --- Jorg Janke wrote: Hi guys, The main causes for the Compiere hold are (1) embedded transactions - i.e. the outer transaction can rollback an inner committed transaction - currently the commit of the inner transaction would commit statements of the inner and outer transaction. (2) the lack of 'proper' PL/SQL Procedure support (a big inconvenience, not the show stopper) compared with what DB/2 and Oracle provides. Compiere developed a Oracle to PostgreSQL online and offline converter - i.e. in goes the Oracle or DB/2 syntax, out comes the PostgreSQL syntax. Initial documentation at http://www.compiere.org/technology/pg/porting.html - see also source code API documentation of the dbPort module in Compiere. We plan to discontinue the above porting kit. Our current plan is to use Java CMP (Container Managed Persistency) - i.e. transaction management in Java for complete database independence with databases with a JDBC 3.0 driver. Cheers, Jorg Janke (203) 445-9503 http://www.compiere.org Smart ERP CRM Business Solution for Distribution and Service globally General questions/issues: http://sourceforge.net/forum/?group_id=29057 Support via: http://sourceforge.net/tracker/?group_id=29057atid=410216 -Original Message- From: Bruce Momjian [mailto:[EMAIL PROTECTED]] Sent: 01 December, 2002 17:45 To: Justin Clift Cc: PostgreSQL Hackers Mailing List; Jorg Janke Subject: Re: [HACKERS] Does anyone know what embedded transactions are? Justin Clift wrote: Hi guys, Was just looking at the project page for Compiere, an Open Source ERP+CRM solution that is usually in the top 10 most popular ERP+SourceForge projects. They were attempting to port Compiere from Oracle to PostgreSQL, but have stopped (apparently) because PostgreSQL doesn't support embedded transations. http://www.compiere.org/technology/independence.html Does anyone know what they're talking about? I assume it is: BEGIN; ... BEGIN; ... COMMIT; COMMIT; That thing I am trying to do for 7.4. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Patch to make Turks happy.
I am not going to apply this patch because I think it will mess up the
handling of other locales.
---
Nicolai Tufar wrote:
Hi,
Yet another problem with Turkish encoding. clean_encoding_name()
in src/backend/utils/mb/encnames.c uses tolower() to convert locale
names to lower-case. This causes errors if locale name contains
capital I and current olcale is Turkish. Some examples:
aaa=# \l
List of databases
Name| Owner | Encoding
---+---+--
aaa | pgsql | LATIN5
bbb | pgsql | LATIN5
template0 | pgsql | LATIN5
template1 | pgsql | LATIN5
(4 rows)
aaa=# CREATE DATABASE ccc ENCODING='LATIN5';
ERROR: LATIN5 is not a valid encoding name
aaa=# \encoding
SQL_ASCII
aaa=# \encoding SQL_ASCII
SQL_ASCII: invalid encoding name or conversion procedure not found
aaa=# \encoding LATIN5
LATIN5: invalid encoding name or conversion procedure not found
Patch, is a simple change to use ASCII-only lower-case conversion
instead of locale-dependent tolower()
Best regards,
Nic.
*** ./src/backend/utils/mb/encnames.c.origMon Dec 2 15:58:49 2002
--- ./src/backend/utils/mb/encnames.c Mon Dec 2 18:13:23 2002
***
*** 407,413
for (p = key, np = newkey; *p != '\0'; p++)
{
if (isalnum((unsigned char) *p))
! *np++ = tolower((unsigned char) *p);
}
*np = '\0';
return newkey;
--- 407,416
for (p = key, np = newkey; *p != '\0'; p++)
{
if (isalnum((unsigned char) *p))
! if (*p = 'A' *p = 'Z')
! *np++ = *p + 'a' - 'A';
! else
! *np++ = *p;
}
*np = '\0';
return newkey;
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] 7.4 Wishlist
Kevin Brown wrote: Christopher Kings-Lynne [EMAIL PROTECTED] wrote: Hi guys, Just out of interest, if someone was going to pay you to hack on Postgres for 6 months, what would you like to code for 7.4? Well, on top of the oft-requested replication support and savepoint support, I'd like to see UPDATE, er, updated to be able to make use of cursors. I think this could be easily done by using the tid of the cursor row for the update, assuming there is a clear tid for the SELECT. Jan has talked about doing that. I'd also like to see (if this is even possible) a transaction isolation mode that would make it possible for multiple concurrent updates to the same row to happen without blocking each other (I imagine one way to make this possible would be for the last transaction to commit to be the one that wins. Each transaction that commits gets its updates written so that other transactions that begin after they commit will see them, of course). Neither read committed nor serialized modes offer this. Don't know if it's possible, but it would be nice (such that a transaction sees the database as if it has it all to itself and doesn't block on updates)... How would you do the update if you don't know of the transaction commits or aborts? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Debian pacakges of 7.3
Debian packages of 7.3 for i386 architecture are available in Debian's unstable archive, as those people tracking unstable will already have noticed. I will get round to producing packages for stable when all the immediate problems are fixed. There are various packaging bugs that I am working on; check the Debian bug repository before filing new bugs -- reportbug is an essential package! debconf is now implemented, so you can choose beforehand whether to try an automatic upgrade or not. libpq++, pgeasy, psqlodbc and pgperl are included in the source package and are available as binary packages. There is a more rigorous divide between library packages and development packages. pgaccess is now a separate source package. Packages for other architectures will be produced by the autobuilders as soon as I clear up any packaging bugs that are blocking them. In the meantime, people wanting packages for other aarchitectures should build from source and let me know what (if anything) goes wrong. -- Oliver Elphick[EMAIL PROTECTED] Isle of Wight, UK http://www.lfix.co.uk/oliver GPG: 1024D/3E1D0C1C: CA12 09E0 E8D5 8870 5839 932A 614D 4C34 3E1D 0C1C Go ye therefore, and teach all nations, baptizing them in the name of the Father, and of the Son, and of the Holy Ghost; Teaching them to observe all things whatsoever I have commanded you; and, lo, I am with you alway, even unto the end of the world. Amen. Matthew 28:19,20 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [ADMIN] how to alter sequence.
On Wed, 2002-12-04 at 12:29, raja kumar thatte wrote: Hai friends, I have a sequence called raj_seq with max value 3000. ... now i wanted to increase the max value of the raj_seq to 999. How to do this change? If i drop and recreate the raj_seq, then i have to recreate the table and all triggers working on that table.But it is not an acceptable solution. So with out droping raj_seq , how do I solve this problem. Unfortunately there doesn't seem to be any easy way to do this. There is no ALTER SEQUENCE command and you can't use UPDATE on a sequence. Hackers: Could this be a TODO item for 7.4? The easiest way to do this at present is probably to dump the database, edit the dump to change the sequence max_value and then recreate the database from the edited dump. I presume you used CREATE SEQUENCE in order to get such a low max_value. If it were created from a SERIAL datatype, you would also have to edit the table definition to use a pre-created sequence. There is no means of specifying a max_value using SERIAL. -- Oliver Elphick [EMAIL PROTECTED] LFIX Limited ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [ADMIN] how to alter sequence.
Oliver Elphick kirjutas K, 04.12.2002 kell 19:06: On Wed, 2002-12-04 at 12:29, raja kumar thatte wrote: Hai friends, I have a sequence called raj_seq with max value 3000. ... now i wanted to increase the max value of the raj_seq to 999. How to do this change? If i drop and recreate the raj_seq, then i have to recreate the table and all triggers working on that table.But it is not an acceptable solution. So with out droping raj_seq , how do I solve this problem. Unfortunately there doesn't seem to be any easy way to do this. There is no ALTER SEQUENCE command and you can't use UPDATE on a sequence. Hackers: Could this be a TODO item for 7.4? This seems to work - as an example why we need the TODO ;) hannu=# update seq set max_value = 99; ERROR: You can't change sequence relation seq hannu=# update pg_class set relkind = 'r' where relname = 'seq'; UPDATE 1 hannu=# update seq set max_value = 99; UPDATE 1 hannu=# update pg_class set relkind = 'S' where relname = 'seq'; UPDATE 1 hannu=# select * from seq; sequence_name | last_value | increment_by | max_value | min_value | cache_value | log_cnt | is_cycled | is_called ---++--+---+---+-+-+---+--- seq | 1 |1 |99 | 1 | 1 | 1 | f | f (1 row) I can't really recommend it, because it may (or may not ;) have some unwanted behaviours as well; The easiest way to do this at present is probably to dump the database, edit the dump to change the sequence max_value and then recreate the database from the edited dump. I presume you used CREATE SEQUENCE in order to get such a low max_value. If it were created from a SERIAL datatype, you would also have to edit the table definition to use a pre-created sequence. There is no means of specifying a max_value using SERIAL. -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [ADMIN] how to alter sequence.
Around 20:41 on Dec 4, 2002, Hannu Krosing said:
What's wrong with this:
dustin=# create sequence test_seq;
CREATE SEQUENCE
dustin=# select nextval('test_seq');
nextval
-
1
(1 row)
dustin=# select setval('test_seq', );
setval
(1 row)
dustin=# select nextval('test_seq');
nextval
-
1
(1 row)
# Oliver Elphick kirjutas K, 04.12.2002 kell 19:06:
# On Wed, 2002-12-04 at 12:29, raja kumar thatte wrote:
# Hai friends,
# I have a sequence called raj_seq with max value 3000.
# ...
# now i wanted to increase the max value of the raj_seq
# to 999.
# How to do this change?
# If i drop and recreate the raj_seq, then i have to
# recreate the table and all triggers working on that
# table.But it is not an acceptable solution.
# So with out droping raj_seq , how do I solve this
# problem.
#
# Unfortunately there doesn't seem to be any easy way to do this. There
# is no ALTER SEQUENCE command and you can't use UPDATE on a sequence.
#
# Hackers: Could this be a TODO item for 7.4?
#
# This seems to work - as an example why we need the TODO ;)
#
# hannu=# update seq set max_value = 99;
# ERROR: You can't change sequence relation seq
# hannu=# update pg_class set relkind = 'r' where relname = 'seq';
# UPDATE 1
# hannu=# update seq set max_value = 99;
# UPDATE 1
# hannu=# update pg_class set relkind = 'S' where relname = 'seq';
# UPDATE 1
# hannu=# select * from seq;
# sequence_name | last_value | increment_by | max_value | min_value |
# cache_value | log_cnt | is_cycled | is_called
#
---++--+---+---+-+-+---+---
# seq | 1 |1 |99 | 1
# | 1 | 1 | f | f
# (1 row)
#
# I can't really recommend it, because it may (or may not ;) have some
# unwanted behaviours as well;
#
#
#
# The easiest way to do this at present is probably to dump the database,
# edit the dump to change the sequence max_value and then recreate the
# database from the edited dump. I presume you used CREATE SEQUENCE in
# order to get such a low max_value. If it were created from a SERIAL
# datatype, you would also have to edit the table definition to use a
# pre-created sequence. There is no means of specifying a max_value using
# SERIAL.
# --
# Hannu Krosing [EMAIL PROTECTED]
#
# ---(end of broadcast)---
# TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
#
#
--
SPY My girlfriend asked me which one I like better.
pub 1024/3CAE01D5 1994/11/03 Dustin Sallings [EMAIL PROTECTED]
|Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE
L___ I hope the answer won't upset her.
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [ADMIN] how to alter sequence.
On Wed, Dec 04, 2002 at 09:33:52AM -0800, Dustin Sallings wrote:
Around 20:41 on Dec 4, 2002, Hannu Krosing said:
What's wrong with this:
dustin=# create sequence test_seq;
CREATE SEQUENCE
dustin=# select nextval('test_seq');
nextval
-
1
(1 row)
dustin=# select setval('test_seq', );
setval
(1 row)
dustin=# select nextval('test_seq');
nextval
-
1
(1 row)
Dustin --
The thread here is about how to raise the *max* value for the sequence,
not how to set the current value higher. The sequence in question was
created with a too-low maximum value (see help on CREATE SEQUENCE for
options); the user now wants to raise it.
- J.
--
Joel BURTON | [EMAIL PROTECTED] | joelburton.com | aim: wjoelburton
Independent Knowledge Management Consultant
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] [ADMIN] how to alter sequence.
Around 12:44 on Dec 4, 2002, Joel Burton said: # The thread here is about how to raise the *max* value for the sequence, # not how to set the current value higher. The sequence in question was # created with a too-low maximum value (see help on CREATE SEQUENCE for # options); the user now wants to raise it. Ahh, OK. Seemed too obvious. :) -- SPY My girlfriend asked me which one I like better. pub 1024/3CAE01D5 1994/11/03 Dustin Sallings [EMAIL PROTECTED] |Key fingerprint = 87 02 57 08 02 D0 DA D6 C8 0F 3E 65 51 98 D8 BE L___ I hope the answer won't upset her. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] [ADMIN] how to alter sequence.
On Wed, 2002-12-04 at 17:33, Dustin Sallings wrote:
What's wrong with this:
dustin=# create sequence test_seq;
CREATE SEQUENCE
dustin=# select nextval('test_seq');
nextval
-
1
(1 row)
dustin=# select setval('test_seq', );
setval
(1 row)
dustin=# select nextval('test_seq');
nextval
-
1
(1 row)
It's not the issue. The original question was how to change the upper
limit of the sequence's range, not its current value.
junk=# create sequence foo_seq maxvalue 3000;
CREATE SEQUENCE
junk=# select nextval('foo_seq');
nextval
-
1
(1 row)
junk=# select setval('foo_seq', 99);
ERROR: foo_seq.setval: value 99 is out of bounds (1,3000)
--
Oliver Elphick [EMAIL PROTECTED]
LFIX Limited
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
Re: [HACKERS] [ADMIN] how to alter sequence.
Oliver Elphick wrote: On Wed, 2002-12-04 at 12:29, raja kumar thatte wrote: Hai friends, I have a sequence called raj_seq with max value 3000. ... now i wanted to increase the max value of the raj_seq to 999. How to do this change? If i drop and recreate the raj_seq, then i have to recreate the table and all triggers working on that table.But it is not an acceptable solution. So with out droping raj_seq , how do I solve this problem. Unfortunately there doesn't seem to be any easy way to do this. There is no ALTER SEQUENCE command and you can't use UPDATE on a sequence. Gee, I thought they could just update the sequence table, but I see: test= update yy set max_value = 100; ERROR: You can't change sequence relation yy Hackers: Could this be a TODO item for 7.4? Added to TODO: * Add ALTER SEQUENCE to modify min/max/increment/cache/cycle values -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
