Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
Tom Lane wrote: Aside from the reality that apps aren't very consistent about their quoting behavior, the fly in this ointment is that whenever you query the database catalogs you will see the stored spelling of the name. So apps that rely on seeing the same spelling in the catalog that they entered could break. (In practice this doesn't seem to be as big a problem as the sloppy-quoting-behavior issue, though.) Shouldn't apps only really be querying the information schema if they're expecting spec compliant behavior? If so, a GUC variable with an access function ought to be enough to get up or down casing as desired, I'd think. Joe ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Do we prefer software that works or software that looks good?
On Sat, 24 Apr 2004, Shachar Shemesh wrote: Tom Lane wrote: So what I'm holding out for is a design that lets me continue to see the current behavior if I set a GUC variable that says that's what I want. This seems possible (not easy, but possible) if we are willing to require the choice to be made at compile time ... but that sounds too restrictive to satisfy anybody ... what we need is a design that supports such a choice per-session, and I dunno how to do that. In other words, you are going to reject the simpler solutions that treat this as a transition problem, because of asthetic issue? Not even program design issue, mind you. Sounds strange to me, and also pretty much guarentees that this will never happen. That would be a shame. [ Tom, we know your opinion on the first part of the next paragraph, so you don't need to reply to that part. ;) ] Are we going to get rid of the current behavior entirely? If so, how are we going to handle issues like current databases with names like foo and FOO (and what if the name was given as foo)? If not, when can one set the folding options and how do we (in the long term) make the database work properly in both settings. Things like don't worry about the catalog entries don't fly when your standard functions are defined and looked up there. Depending on the answers to the above, we need to think about things like the transitional plans put forth. Do these plans actually help transition things. The fold up and down compare one then the other on a failure of the first may be fairly invasive changes, still has problems when quotes are used inconsistently and can also silently change behavior from old versions (on that database mentioned above, what does select * from foo do, is it the same as before?). These may or may not be huge issues and it may or may not be easily solvable, but these things need to be figured out IMHO before something can be considered a solution. ---(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] Do we prefer software that works or software that looks good?
-Original Message- From: Stephan Szabo [mailto:[EMAIL PROTECTED] Sent: 24 April 2004 08:43 To: Shachar Shemesh Cc: Tom Lane; Robert Treat; Dennis Bjorklund; Bruce Momjian; PostgreSQL-development; PostgreSQL advocacy Subject: Re: [HACKERS] Do we prefer software that works or software that looks good? Are we going to get rid of the current behavior entirely? If so, how are we going to handle issues like current databases with names like foo and FOO (and what if the name was given as foo)? If not, when can one set the folding options and how do we (in the long term) make the database work properly in both settings. Things like don't worry about the catalog entries don't fly when your standard functions are defined and looked up there. I'm unfamiliar with the code involved so this may be a waste of bandwidth, but it seems to me that any selection of upper or lower case folding should be done on a per-database basis - probably specified in the create database statement, and flagged in pg_database. If its done per-database then any issues of FOO == foo go away unless someone loads a lowercase dump into an uppercase database - in which case it's up to them to resolve any conflicts prior to loading the dump file. Regards, Dave. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Do we prefer software that works or software that looks good?
Stephan Szabo wrote: [ Tom, we know your opinion on the first part of the next paragraph, so you don't need to reply to that part. ;) ] Are we going to get rid of the current behavior entirely? I doubt that will be a good idea. You want to let applications created for previous versions of PostgreSQL continue to work. The idea, I think, is to have either a DB wide, or a session wide, option to have it either way. We may have to create a DB conversion tool, that converts a DB from one way to the other (and changes the case of functions, along the way). If so, how are we going to handle issues like current databases with names like foo and FOO (and what if the name was given as foo)? I think these are really rare. The conversion tool can warn about these cases. If not, when can one set the folding options and how do we (in the long term) make the database work properly in both settings. I don't think having the same DB work in both folding options is really a big issue. Having two databases on the same server, one this way and one the other is, however. You don't want to install two database servers, merely because you have two applications developed for two different PG versions. Things like don't worry about the catalog entries don't fly when your standard functions are defined and looked up there. Answer above. Depending on the answers to the above, we need to think about things like the transitional plans put forth. Do these plans actually help transition things. I think they do. The idea is to be as complaining and as verbose during transition as possible. Ideally, if some breakpoint can be triggered each time a double lookup takes place (thus knowing that the client app is calling the wrong way), this will allow converting apps in almost no time at all. The fold up and down compare one then the other on a failure of the first may be fairly invasive changes, In what way invasive? still has problems when quotes are used inconsistently The main issue, as far as I'm concerned, is not with PG apps that need to be ported to the new scheme. I don't have any qualm with never deprecating the lowercase folding. This, of course, puts a burden on utilities that work as infrastructure to always quote or always not-quote (depending on exact semantics), but that, I believe, is solveable. My problem is with applications written for other, more standard complient, databases, and with porting these into PG. As such, if the app uses inconsistent quoting, it today relies on uppercase folding, and will not have any problem. and can also silently change behavior from old versions (on that database mentioned above, what does select * from foo do, is it the same as before?). These may or may not be huge issues and it may or may not be easily solvable, but these things need to be figured out IMHO before something can be considered a solution. I agree. It's just that I don't think this is a big issue, given the fact that I don't think we intend to deprecate the lowercase folding any time soon. Shachar Remove advocacy from the CC. I don't think it's related there any more. -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Invalid pg_hba.conf = Postgres crash
Hi all, running postgres 7.4.1 2 different behavior: - Inserting the following invalid line on pg_hba.conf host allall127.0.0.1trust sameuser # HANG the future connections will hang leaving a postgres process running - Inserting the following line instead will crash postgres host all 127.0.0.1 trust sameuser# CRASH #psql kalman psql: server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. and in the log: LOG: server process (PID 17656) was terminated by signal 11 LOG: terminating any other active server processes LOG: all server processes terminated; reinitializing LOG: database system was interrupted at 2004-04-24 12:27:37 CEST LOG: checkpoint record is at 0/4877FD38 LOG: redo record is at 0/4877FD38; undo record is at 0/0; shutdown TRUE LOG: next transaction ID: 195700; next OID: 5718523 LOG: database system was not properly shut down; automatic recovery in progress LOG: record with zero length at 0/4877FD78 LOG: redo is not required LOG: database system is ready Regards Gaetano Mendola ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Do we prefer software that works or software that looks good?
On Saturday 24 April 2004 01:23, Shachar Shemesh wrote:
Tom Lane wrote:
PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE
to make the point about readability. But if you want to argue the
point with me, I'll be happy to do that for the rest of the thread.
Yes, it's a well known rhetoric technique. Take whatever argument your
opponent say, and exagerate it to an absurd.
Kind of like changing the subject line of a thread to imply your side of the
argument is the one that has technical merit and the other side is being
petty and/or frivolous? Anyone who has studied software useability will
know that uppercase should, in general, be avoided as it hurts readability.
It isn't about looking pretty, it's about being more usable.
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Do we prefer software that works or software that looks good?
Robert Treat wrote: On Saturday 24 April 2004 01:23, Shachar Shemesh wrote: Tom Lane wrote: PS: I resisted the temptation to SET THIS MESSAGE IN ALL UPPER CASE to make the point about readability. But if you want to argue the point with me, I'll be happy to do that for the rest of the thread. Yes, it's a well known rhetoric technique. Take whatever argument your opponent say, and exagerate it to an absurd. Kind of like changing the subject line of a thread to imply your side of the argument is the one that has technical merit and the other side is being petty and/or frivolous? It is my understanding that the discussion with Tom was 100% about the question in the subject line. There is no question that the SQL standard dictates that unquoted identifiers should be folded to uppercase. There is no question (not from me) that upper case is ugly. The only question is whether we should prefer standard to asthetic. Anyone who has studied software useability will know that uppercase should, in general, be avoided as it hurts readability. You convinced me! let's change the SQL standard. It isn't about looking pretty, it's about being more usable. Robert Treat Ok. I'm willing to change the subject to are hurting eyes due to uppercase preferable to changing lots of code when migrating to PG from other database due to standard incomplience, if it would make you feel better. The point is that I am not against lower case, or pro uppercase. I HATE uppercase. I do think, however, that standards should be followed. The question is, when all is said and done, which is more useable. A DB that presents unquoted identifiers as uppercase, or one that allows easier migration of client apps from other DBs. I'll also mention that if asthetic/readability is all that bothers you, we can add a flag to psql that displays all caps as lowercase. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] The case for preserving case.
Hi EMF, emf wrote: Hello, postgresql hackers. All of this breaks when I start to use postgresql, because all of the attributes become lowercased. Well, I'm afraid that something will have to change in the app. Your email arrives while we are in the middle of a small war around the subject of case changing, but none of the options going around at the moment will match your request. The two options considered are leaving things as they are (con: non standard complient) or folding to uppercase (con: ugly and requires transition, unfortunetly, in this order). Fixing this problem involves one of three things: 1.) rewriting all the code to have lowercased identifiers. This is effectively renaming everything, as long camel case attributes become much harder to read when they're lowercased. This also changes the clients' preferred coding standard. Ok, so don't do it. 2.) using double quotes around all identifiers in sql statements. As you're probably aware, there's no string format in PHP that lets you write double quote marks unescaped (and do variable substitution), so this involves rewriting hundreds of lines and imposing ongoing overhead for every SQL query. But is consistant with both SQL standard, and with current MySQL setup. This will also make porting the app to further database, such as commercial ones, easier. I think that is the proper way or you to go. 3.) escaping 4 lines in src/backend/parser/scansup.c , where identifiers are lowercased. You can do that for your own postgres installation, if you really like. I'm not a member of the steering commitee, but I doubt you'll manage to get such a patch accepted. Maybe as a per-session setting I understand that the reason for lowercasing is because odbc connections, etc expect case insensitivity, but the current behaviour isn't an SQL standard Neither is yours, though. If we are going to change it, we might as well change it to the standard, don't you think? nor is it really case insensitivity. It's as close as you can get without losing the benefits of doing hash lookups. I would love case insensitivity with case preservation, but since that evidently is a more complicated option, I would like to know how I can formulate the 'case preserving' option in a way to make it palatable for inclusion. Can't help you there, unless you want to compile Postgres yourself. Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Do we prefer software that works or software that looks good?
On Saturday 24 April 2004 08:09, Shachar Shemesh wrote:
Robert Treat wrote:
Anyone who has studied software useability will
know that uppercase should, in general, be avoided as it hurts
readability.
You convinced me! let's change the SQL standard.
We plan to, right after we have PostgreSQL achieve world domination. But we
can't abondon lower case now or it will weaken the argument when that time
comes. :-)
Ok. I'm willing to change the subject to are hurting eyes due to
uppercase preferable to changing lots of code when migrating to PG from
other database due to standard incomplience, if it would make you feel
better.
ouch. s/code when/code from crappily written apps when/:-)
The point is that I am not against lower case, or pro uppercase. I HATE
uppercase. I do think, however, that standards should be followed. The
question is, when all is said and done, which is more useable. A DB that
presents unquoted identifiers as uppercase, or one that allows easier
migration of client apps from other DBs.
IMHO apps that apply quoted identifiers willy nilly are busted anyway, and it
is only by coincidence that they work on other databases if they work at all.
(And it's by extremely unfortunate coincidence that they might be spec
complient in that behavior.. but hey.)
Oh well... let's see if we can find a way to support both...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Do we prefer software that works or software that looks good?
Robert Treat wrote: IMHO apps that apply quoted identifiers willy nilly are busted anyway, Not really. Sometimes the app itself will be very consistent, never applying quotes, but an underlying driver will always apply quotes. The result is a mixed behaviour. There is nothing you or me can do about that. Notice that in the above case, neither app nor driver are violating their mandate, and both are well within their right to do so. So long as the behaviour is regulated by a standard, there is nothing you and I can say against such practices. Oh well... let's see if we can find a way to support both... You are welcome to join the other leg of this thread, then. That one is not CCed to advocacy, as it is 100% technical. Robert Treat Shachar -- Shachar Shemesh Lingnu Open Source Consulting http://www.lingnu.com/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] contrib/trgm beta release
Hi there, Christopher Kings-Lynne has kindly contributed documentation to our contrib/trgm module, which implements fuzzy search with GiST index support. Nice thing about this module is that it could be used for spelling support in tsearch2 and it doesn't depends on language. Download it from http://www.sai.msu.su/~megera/postgres/gist/ We plan to add some features in may day. Your comments and suggestions are welcome. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, Apr 23, 2004 at 10:56:43PM -0700, Joe Conway wrote: Tom Lane wrote: Aside from the reality that apps aren't very consistent about their quoting behavior, the fly in this ointment is that whenever you query the database catalogs you will see the stored spelling of the name. So apps that rely on seeing the same spelling in the catalog that they entered could break. (In practice this doesn't seem to be as big a problem as the sloppy-quoting-behavior issue, though.) Shouldn't apps only really be querying the information schema if they're expecting spec compliant behavior? If so, a GUC variable with an access function ought to be enough to get up or down casing as desired, I'd think. Some questions: Is there a way to make this work? At what level should the current system be modified? If the parser or lexer is to be modified, are they going to need database access? They are not allowed to, AFAIR. One could invent a GUC setting for this, and have it set at database creation time. How would shared catalogs be handled? Should we have a template database for uppercase and another one for lower case databases? Should non-shared catalogs be handled in a special way? Or maybe it is a compilation switch. What issues would arise? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Before you were born your parents weren't as boring as they are now. They got that way paying your bills, cleaning up your room and listening to you tell them how idealistic you are. -- Charles J. Sykes' advice to teenagers ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] contrib vs. gborg/pgfoundry for replication solutions
Marc G. Fournier [EMAIL PROTECTED] writes: I don't agree with this, since mirrors are web mirrors ... but I do like the 'Contrib' pointing to gborg/projects ... Yeah, I like the contrib link idea too. Much of the recent discussion comes down to gborg not being visible enough. However ... how do we handle things once pgfoundry is online too? (I suppose two links labeled Old Contrib and New Contrib might serve as a forcing function to get projects to migrate over ;-)) If there is going to be a change, i.e. Great Bridge is going away, and being replaced with pgfoundary, I would suggest that you notify everyone of a date and make it happen. Conversely, on pgfoundary, make a link to gborg calling it old projects or something like that. Take a look at this mock-up: http://www.mohawksoft.com/PostgreSQL.html (I am not a good web developer, I just moved a few things around, but I hope you get what I'm trying to say) A good web design makes no assumption that the visitor knows anything about you. Like mirrors or download, whis would tend to confuse first time visitors. A single Download link should take the user to a page that explains http/ftp and provides the various source links. Similarly, a Contrib should take the user to a single place, gborg now, pgfoundary later. Pgfoundary can then direct them to gborg if the project they are searching for is not there. The main problem with hard to use or cluttered web sites is that techies like ourselves tend to put too much up front. Simple is better. Open up a browser window on www.PostgreSQL.org. Don't resize window, assume 1024x768 screen, and maybe 3/4 or 2/3 of the screen is taken by the browser Window. What do you see? You have to scroll to see gborg and the odbc driver and replication, two very important projects. All the visual clues needed to find things need to be seen in that first window or people will not see them. In my screen, the bottom says User Survey and Websites There are no visual clues that something like gborg would show up if I scrolled down. Yes, you can The user should just scroll down, but they don't. Period. It is like the first paragraph in a news article, if you don't grap the user there, you won't. Lastly there is grouping and relevence. Why is gborg lower on the page than User Survey? Isn't gborg more important to the users than the user survey? Why are there two links to gborg, one under websites and the other under gborg, abd both are under the scroll line. Why is there a link to mailing list archives under websites and as a top level link on the menu? All this critisizm aside, I generally like the look of the website, even thought the elephant banner doesn't line up with the PostgreSQL banner :-) It is just that the content and the presentation can be streamlined, taking out redundant links and info, removing logically similar choices i.e. Download and Mirrors, adding Contrib, and organizing more important stuff at the top and down the middle, with less relvent stuff to the right. ---(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] Do we prefer software that works or software that looks good?
On Sat, 24 Apr 2004, Shachar Shemesh wrote: Stephan Szabo wrote: Are we going to get rid of the current behavior entirely? I doubt that will be a good idea. You want to let applications created for previous versions of PostgreSQL continue to work. The idea, I think, is to have either a DB wide, or a session wide, option to have it either way. We may have to create a DB conversion tool, that converts a DB from one way to the other (and changes the case of functions, along the way). I'm going to assume that we're making the assumption that the user isn't going to try to do this on databases where it doesn't work? I think we've lost any information about quoting (was that named foo or foo?) so I don't think we can meaningfully make a current PostgreSQL app that's inconsistent about quoting work after the conversion. I think this is reasonable, but others may disagree. If so, how are we going to handle issues like current databases with names like foo and FOO (and what if the name was given as foo)? I think these are really rare. The conversion tool can warn about these cases. I agree, but we need to think about these cases (and any other wacky cases like this) so that we can warn about these cases rather than just not handle them. If not, when can one set the folding options and how do we (in the long term) make the database work properly in both settings. I don't think having the same DB work in both folding options is really a big issue. Having two databases on the same server, one this way and one the other is, however. You don't want to install two database servers, merely because you have two applications developed for two different PG versions. To be honest for me, it really doesn't feel much different than an app written for 7.2 and one written for 7.4 where the former uses things that were removed and so cannot be moved to 7.4 without changes. But that's just an option. Things like don't worry about the catalog entries don't fly when your standard functions are defined and looked up there. Answer above. Okay, under that world view (as opposed to on the fly), I think the only issues come in from shared catalogs, most importantly user names. This is certainly solvable, but we need to consider how we handle them when given to commands like ALTER USER or CREATE USER. The fold up and down compare one then the other on a failure of the first may be fairly invasive changes, In what way invasive? Right now AFAIK most of the case folding stuff pretty much happens in one place during normal queries and the identifier string you get out has the post-folding identifier for unquoted or the contained literal for quoted. In a system where you fold both directions, I can see a few obvious options: a) keep around the real identifier that was given plus whether or not it was quoted. b) keep around both folded identifiers (for non-quoted names). c) fold one direction then the other. This may potentially do the wrong thing in some locales I don't know how you were planning to handle this issue so I don't know if any of these scenarios were what you were thinking of or if you had a better idea. I think all of these potentially may need to touch at least some places where the identifier is used and I think all of them need information that is not AFAIK currently returned from scan.l which means passing that information along (which may change stuff along the way). still has problems when quotes are used inconsistently The main issue, as far as I'm concerned, is not with PG apps that need to be ported to the new scheme. I don't have any qualm with never deprecating the lowercase folding. This, of course, puts a burden on utilities that work as infrastructure to always quote or always not-quote (depending on exact semantics), but that, I believe, is solveable. My problem is with applications written for other, more standard complient, databases, and with porting these into PG. As such, if the app uses inconsistent quoting, it today relies on uppercase folding, and will not have any problem. That sounds like a plus for having the option for full uppercase folding. I have no problems with that (I wouldn't have even looked at initdb if I didn't want to give an option for uppercase folding) but I'm not convinced it actually is a plus for the transitional setting. An app written for full uppercase should work in said option without needing the transitional setting and in fact the transitional setting might do the wrong thing for said application. The only place I can see transitional being useful is for upgrading and testing our own stuff (make the server work, make pg_dump work, etc) and for applications moving from supporting only the lowercase to supporting both or only upper. For the former, it doesn't need to be a truly supported feature if it's going in in a single version, and for the latter, I think as many of the wierd change and such
Re: [HACKERS] What can we learn from MySQL?
On Fri, Apr 23, 2004 at 16:36:57 -0400, [EMAIL PROTECTED] wrote: Ease of use is VERY important, but few suggestions that address this are ever really accepted. Yes, focusing on the functionality is the primary concern, but how you set it up and deploy it is VERY important. You guys need to remember, people are coming from a world where MySQL, Oracle, and MSSQL all have nice setup programs. nice must be in the eye of the beholder. I have used Oracle's installer to install a client and was not amused by it need hundreds of megabtyes to do a client install. ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] GUC custom variables
Hi, I'm about to finalize my patch for GUC custom variables. I did find the place to add the documentation for the custom_variable_classes variable that I added but I can't find any documentation related to GUC functions. I've added 5 new functions. 4 to allow modules to define new variables and 1 to assert that no 'stray' variables persists after the definition. Where to I put the documentation? A comment for each method, sure, but shouldn't there be some sgml for this somewhere? Kind regards, Thomas Hallgren ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [pgsql-advocacy] [HACKERS] What can we learn from MySQL?
On Fri, Apr 23, 2004 at 11:45:28AM -0400, Robert Treat wrote: lower will now simply be folder upper. the only people who will have a problem are those who quote on one end but not the other, which is bad practice anyways... so i would say if your serious about it, make the patch as GUC case_folding for upper or lower and get a taste for what breaks inside the db. If it were that easy, it wouldn't matter, right? That is, if you had a system which was either consistently quoted or consistently unquoted, then you'd never run into the problem of the upper-or-lower question. It's precisely _because_ systems often have been maintained by various cranks for 20 years that it's a problem. One guy thinks quoting is stupid. Another thinks that if you don't quote, you're asking for trouble, A third has been rigourous in following the quoting convention he learned in his last job. The ship date is three weeks away, and there are 802 P1 bugs filed. What chance do you think there is that someone is going to scrub all the checkins of quotes (or apply them carefully)? This is _exactly_ why standards compliance for this stuff matters, and why backward comaptibility is also a top priority. A -- Andrew Sullivan | [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] What can we learn from MySQL?
I think that when considering install, it is very important, if not critical, that we all understand who is doing the install. Certainly if it is a person much like us, meaning people on the hackers/development list, we can all handle more terse installs. Personally, I like the freedom of choices, and not having a result of hundreds of megs that I know are not required. On the other hand, we are really a minority. The masses certainly like simple installs, regardless of just how many megs are used, needed or not. If the masses really cared, then Microsoft would be in trouble. But, as we can see in the market place, they don't. In fact, most people think more is better. Somehow they think 2 CDROMs is better than 1 CDROM. So, if it takes an extra 200 meg to make a glitsy install with little videos expounding on how great Postgresql is, then for that user, it will make all of the difference. We need to remember who the audience is. We cannot gain mass market share otherwise. My 2 cents, won't buy coffee, Jordan Henderson --- Bruno Wolff III [EMAIL PROTECTED] wrote: On Fri, Apr 23, 2004 at 16:36:57 -0400, [EMAIL PROTECTED] wrote: Ease of use is VERY important, but few suggestions that address this are ever really accepted. Yes, focusing on the functionality is the primary concern, but how you set it up and deploy it is VERY important. You guys need to remember, people are coming from a world where MySQL, Oracle, and MSSQL all have nice setup programs. nice must be in the eye of the beholder. I have used Oracle's installer to install a client and was not amused by it need hundreds of megabtyes to do a client install. ---(end of broadcast)--- TIP 8: explain analyze is your friend ---(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] Invalid pg_hba.conf = Postgres crash
Gaetano Mendola [EMAIL PROTECTED] writes:
host allall127.0.0.1trust sameuser # HANG
the future connections will hang leaving a postgres process
running
- Inserting the following line instead will crash postgres
host all 127.0.0.1 trust sameuser# CRASH
I was able to reproduce the crash but not the hang. Would you see if
the attached patch fixes both symptoms on your machine?
regards, tom lane
Index: ip.c
===
RCS file: /cvsroot/pgsql-server/src/backend/libpq/ip.c,v
retrieving revision 1.23
diff -c -r1.23 ip.c
*** ip.c12 Sep 2003 20:18:51 - 1.23
--- ip.c24 Apr 2004 20:09:21 -
***
*** 67,74
*/
int
getaddrinfo_all(const char *hostname, const char *servname,
! const struct addrinfo * hintp, struct addrinfo **
result)
{
#ifdef HAVE_UNIX_SOCKETS
if (hintp != NULL hintp-ai_family == AF_UNIX)
return getaddrinfo_unix(servname, hintp, result);
--- 67,77
*/
int
getaddrinfo_all(const char *hostname, const char *servname,
! const struct addrinfo *hintp, struct addrinfo **result)
{
+ /* not all versions of getaddrinfo() zero *result on failure */
+ *result = NULL;
+
#ifdef HAVE_UNIX_SOCKETS
if (hintp != NULL hintp-ai_family == AF_UNIX)
return getaddrinfo_unix(servname, hintp, result);
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Current CVS tip segfaulting
On Sat, Apr 24, 2004 at 12:27:14AM -0400, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: It could be a bug, but if it is, it is a different fix than the one I did, I think. Re-reading Alvaro's message, I wondered if cranking logging up to a higher-than-default setting was needed to reproduce the bug. A quick experiment in that line didn't show a problem, but maybe I missed the critical setting. Alvaro, what postgresql.conf settings are you using? I don't touch the standard settings ... log values are from the default installation. In another mail you asked: Which PS_USE_FOO option does your platform use? (See src/backend/utils/misc/ps_status.c) PS_USE_CLOBBER_ARGV AFAICS (ugh, sure uppercase is ugly) ;-) The relevant strace extract is this (3448 is the backend, 3443 is postmaster): 3448 write(2, FATAL: database \asd\ does not exist\n, 38) = 38 3448 send(10, R\0\0\0\10\0\0\0\0E\0\0\0\217SFATAL\0C3D000\0Mdatabase \asd\ does not exist\0F/home/alvherre/CVS/pgsql/source/00orig/src/backend/utils/init/postinit.c \0L264\0RInitPostgres\0\0, 153, 0) = 153 3448 --- SIGSEGV (Segmentation fault) @ 0 (0) --- 3443 ... select resumed )= ? ERESTARTNOHAND (To be restarted) 3443 --- SIGCHLD (Child exited) @ 0 (0) --- Note that the ereport() did get the line number, file and function name, the correct database name, etc. I don't know if the code is changing the ps status after that; it's difficult to attach a debugger to this ... huh wait, I'll try the backend's developer switches. ... plays for a while ... Heh, the -s switch to postmaster seems to behave funny. The bgwriter process appears in T status in ps (stopped), but not the postmaster; if I then send SIGCONT to the bgwriter it seems to continue, it returns to S status but then postmaster doesn't respond correctly to signals (INT or TERM don't shut it down). Has it been always like this? I haven't used this switch before. Anyway, this doesn't allow me to examine the dead backend. Trying postmaster -o -W 60 allows me to attach gdb to the backend before it dies: (gdb) bt #0 0xe410 in ?? () #1 0xbfffeda8 in ?? () #2 0x4025f800 in ?? () from /lib/tls/libc.so.6 #3 0xbfffec04 in ?? () #4 0x401cb460 in nanosleep () from /lib/tls/libc.so.6 #5 0x401cb263 in sleep () from /lib/tls/libc.so.6 #6 0x0818791e in PostgresMain (argc=6, argv=0x82dff18, username=0x82dfee0 alvherre) at stdlib.h:382 #7 0x0815fab0 in BackendRun (port=0x82ed050) at /home/alvherre/CVS/pgsql/source/00orig/src/backend/postmaster/postmaster.c:2664 #8 0x0815f371 in BackendStartup (port=0x82ed050) at /home/alvherre/CVS/pgsql/source/00orig/src/backend/postmaster/postmaster.c:2297 #9 0x0815db6e in ServerLoop () at /home/alvherre/CVS/pgsql/source/00orig/src/backend/postmaster/postmaster.c:1167 #10 0x0815d157 in PostmasterMain (argc=3, argv=0x82deb80) at /home/alvherre/CVS/pgsql/source/00orig/src/backend/postmaster/postmaster.c:928 #11 0x0812f030 in main (argc=3, argv=0x82deb80) at /home/alvherre/CVS/pgsql/source/00orig/src/backend/main/main.c:257 (gdb) cont Continuing. Program received signal SIGSEGV, Segmentation fault. 0x in ?? () (gdb) bt #0 0x in ?? () Whoa! New backend, new gdb, try again: (gdb) break InitPostgres Breakpoint 1 at 0x81f3c3c: file /home/alvherre/CVS/pgsql/source/00orig/src/backend/utils/init/postinit.c, line 230. (gdb) cont Continuing. Breakpoint 1, InitPostgres (dbname=0xc Address 0xc out of bounds, username=0x80e2540 U\211åSPè\222Îøÿ\200= ±*\b) at /home/alvherre/CVS/pgsql/source/00orig/src/backend/utils/init/postinit.c:230 230 boolbootstrap = IsBootstrapProcessingMode(); (gdb) This surely looks suspicious ... (gdb) p dbname $2 = 0xc Address 0xc out of bounds (gdb) frame 1 #1 0x08187581 in PostgresMain (argc=6, argv=0x82dff18, username=0x82dfee0 alvherre) at /home/alvherre/CVS/pgsql/source/00orig/src/backend/tcop/postgres.c:2745 2745InitPostgres(dbname, username); (gdb) p argv $3 = (char **) 0x82dff18 (gdb) p argv[0] $5 = 0x8265402 postgres (gdb) p argv[1] $6 = 0x82aa301 -W (gdb) p argv[2] $7 = 0x82aa304 60 (gdb) p argv[3] $8 = 0xbfffee60 -v196608 (gdb) p argv[4] $9 = 0x826d97a -p (gdb) p argv[5] $10 = 0x82dfefc asd (gdb) p argv[6] $11 = 0x0 (gdb) p dbname $12 = 0x82ea848 asd -- Note that this is not the same as argv[5], it's a copy, and as far as I can see, it's set by the -p option in the switch/case, in tcop/postgres.c line 2391, using strdup. What else? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Syntax error: function hell() needs an argument. Please choose what hell you want to involve. ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Current CVS tip segfaulting
On Fri, Apr 23, 2004 at 10:31:46PM -0400, Tom Lane wrote: Alvaro Herrera [EMAIL PROTECTED] writes: In current (as of a couple hours ago) clean CVS tip sources, without any of my local changes, I'm getting a postmaster segfault when trying to connect to a non existant database. Hmm, works for me with this morning's sources. Bruce created a bug of that ilk a few days ago but fixed it shortly thereafter. Is it possible the anon-CVS server is out of date? Did I already say that I use CVSup? It seems to be up to date with the latest commits, so I don't think this is it. I'm starting to think that this could be a problem with my glibc/kernel combination ... This is linux-2.6.3-7mdk with glibc 2.3.3-10mdk. Is anyone else using Mandrakelinux 10 official? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Nadie esta tan esclavizado como el que se cree libre no siendolo (Goethe) ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Do we prefer software that works or software that looks good?
On Saturday 24 April 2004 09:21, Shachar Shemesh wrote:
Robert Treat wrote:
Oh well... let's see if we can find a way to support both...
You are welcome to join the other leg of this thread, then. That one is
not CCed to advocacy, as it is 100% technical.
I'm already there...
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] The case for preserving case.
On Apr 24, 2004, at 00:48, Tom Lane wrote: You do realize that any such patch would be at least a thousand times larger than that? I am coming from a state of ignorance past the fact that commenting out four lines of code appeared to create the behaviour I desired. I knew that just changing it to match the behaviour *I* wanted isn't the same thing as making a change that could work for everyone; that's why I asked what sort of implementation of this behaviour would be acceptable. And have vast repercussions on existing client code? I don't want to impose this on anyone else, I just want a postgresql that doesn't mangle my case, as case carries meaning in my application. From what I've seen online, other people migrating away from MySQL would like this behaviour to be an option as well. I'm willing to debate this, but not with people who claim it's a four-line change. Do some research. You are welcome to not pay attention to what I have to say; I will probably never be deeply involved in the PostgreSQL codebase. I am willing to do more work to make this option that is very useful to me more widely acceptable. -- Living on earth and in space are the same class of problem. In one, the environment is harshly inimical to humans: in the other, the inverse is true. ~mindlacehttp://mindlace.net ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] The case for preserving case.
On Apr 24, 2004, at 11:17, Jan Wieck wrote: I don't think that we will break backward compatibility for existing PostgreSQL specific code in order to gain CamelCase+MySQL porting ease by adopting an even less standard compliant behaviour than we currently have. I understand and agree that breaking backward compatibility is not an option. As things are today, we are case insensitive for unquoted identifiers and breaking that is not an option. What you do to unquoted identifiers is not case insensitivity, but lowercase folding. I see a chance for getting your desired behaviour, case preservation, only as a side effect if a larger move towards the standard. That sounds great! I'd like to help if I can. This would not be a simple per postmaster config option or even a compiletime setting, but rather a per database option in the pg_database system catalog, chosen at CREATE DATABASE time. This also sounds good, but with my vast ignorance of postgresql, I have no idea the proper way to tell scansup.c to knock it off (or fold up, or fold down) based on something in the pg_database system catalog. The real problem with this is that it has far greater side effects than you seem to imagine yet. [snip described problem] I am probably still not understanding, since if the internals always quote in their queries, it would seem that the internals could continue to use lowercase identifiers regardless of the DB setting. I am certain that most of us are open for a more complete proposal that includes moving towards the ANSI standard, but the change you outlined below is not acceptable. I understand that. I am willing to do work to make a more complete proposal, but I would appreciate some guidance as to how to code something that would be more acceptable. I read in another thread that the stuff going on in scansup.c isn't allowed/shouldn't talk to the database, so I freely admit I don't know how to approach a palatable solution. Worst case scenario, I'm content with keeping my hacked version of postgresql so that I can get this application ported faster. Making that happen fast and taking advantage of postgresql's superior features will help convince my client that the thousands of dollars he's spending in this port were worthwhile ... once I've done that, gradually transitioning to case-insensitive identifiers is possible, but right now all he sees is big transition pain for gain he hasn't seen yet. -- nothing can happen inside a sphere that you could not inscribe upon it. ~mindlacehttp://mindlace.net ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Invalid pg_hba.conf = Postgres crash
Tom Lane wrote: I was able to reproduce the crash but not the hang. Would you see if the attached patch fixes both symptoms on your machine? Yes, problem gone. I discover however that what I was believing an hang was in reality just a delayed crash. Regards Gaetano Mendola ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Multiple statements in one prepare
On 15-Apr-04, at 9:26 AM, Robert Turnbull wrote: How can multiple SQL statements be included in one prepare command? The goal is to reduce chatter between the client and server by submitting an atomic tranasaction set. You can submit multiple PREPARE commands in one query string (separated by semi-colons), so the difference in FE/BE traffic should be negligible. -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
