Re: [HACKERS] allowed user/db variables
Christopher Kings-Lynne wrote: See my followup. Which bits of info would you like to see added that SHOW doesn't reveal? Unlike andreas, I'm not interested in the types and ranges of values, what I need to know is the GUC variables that the user is allowed to set, in particular what they can ALTER USER / SET ... so that I can display that feature... I was considering adding this and the stuff Andreas requested to pg_settings (but not SHOW ALL or SHOW x unless people feel it's important to kept them consistent with pg_settings). Were the Red Hat guys going to do this? Joe ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] Physical Database Configuration
Well, correct solution is to implement tablespaces on which objects like databases, tables and indexes can be put. I have started working on tablespaces (to the extent that I am capable!), based not on the rejected patch, but on Jim's eventual syntax proposal that was never developed. eg. CREATE LOCATION blah AS '/exports/indexes' CREATE DATABASE db WITH LOCATION loc; CREAT TABLE foo (a PRIMARY KEY LOCATION blah) LOCATION blah; ..etc... There was a long discussion on this and there was a tablespaces patch. It was agreed that tablespace as a set of directories would be a good point to start. If anyone wants to help me (as I've not had time to code on it for a while due to phpPgAdmin), then they can email me! I'm working from a top-down perspective - eg. adding new catalog and grammar and support functions before mucking about with low level storage... Chris ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] allowed user/db variables
I was considering adding this and the stuff Andreas requested to pg_settings (but not SHOW ALL or SHOW x unless people feel it's important to kept them consistent with pg_settings). Were the Red Hat guys going to do this? pg_settings would be fine for phpPgAdmin. Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] Physical Database Configuration
I have started working on tablespaces (to the extent that I am capable!), based not on the rejected patch, but on Jim's eventual syntax proposal that was never developed. Hmm... Remember feature freeze is 1st of July. So unless you send out a minimally working patch before that, it won't be considered for 7.4. I have no intention of having it ready anywhere near 7.4 :) I'm working from a top-down perspective - eg. adding new catalog and grammar and support functions before mucking about with low level storage... I would love to hack this one. Especially putting WAL in a location that is configurable, I mean PG knowing where to find it's WAL. This patch won't affect WAL location - that's a separate issue. If you complete the syntactic part, I guess a very very rough patch should be possible before feature freeze but that is way tooo optimistic. Not going to happen :) I haven't done very much on it yet. Chris ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
On Tue, 24 Jun 2003, Dann Corbit wrote: -Original Message- From: The Hermit Hacker [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 24, 2003 6:10 PM To: Dann Corbit Cc: The Hermit Hacker; Jan Wieck; scott.marlowe; Bruce Momjian; Tom Lane; Jason Earl; PostgreSQL-development Subject: RE: [HACKERS] Two weeks to feature freeze On Tue, 24 Jun 2003, Dann Corbit wrote: I did something about it. I raised the issue. Is it really so that whoever it is that raises a question is also the one who must fix the issue raised? A strange model indeed. Its worked for us ... Wait, I know what should make you happy ... it won't get anytihng done, but ... Bruce, can you add * Improve Testing to the TODO list It is surely a titanic mistake to bring up any issue on this list if you do not plan to fix it yourself. No, it's not. But you have to realize that when you bring up a problem without a solution, you are, in effect, asking someone else to solve your problem. I do that all the time. I don't code postgresql (well, I've hacked around in it a bit for fun, but most of it is over my head.) So, then I bring up something (like the screwy date mangling / parsing misfeature we've been discussing this last week) I KNOW I'm asking the programmers for a favor to fix it, and I know that if they all said, no, we don't have time to fix it, if you want it done you'd better get hacking, then I can either get hacking or wait until someone has time to fix it. I.e. I have to be civil and present my case in a convincing enough manner to get someone else to do it. The bigger the change, the more likely it is that it'll get thrown back at the person suggesting it. A prime example is using a threaded model. About every three months or so someone shows up waving their hands about how Postgresql just can't be fast without threads. No code, no benchmarks, no proof, just a rough feeling they got from reading a magazine article. Invariably, the issue is far more complex than just make Postgresql threaded and the person suggesting it can justify why someone else should spend months doing it, but they can't be bothered themselves. In the Open Source universe, if you want a feature, you have to be willing to pay for it. Whether that's with code or a checkbook, either way, TANSTAAFL. In the case of better testing, if you're willing to get out your checkbook and start pumping out cash to a few of the developers here on the list, I'd sure someone would jump right up and start writing your test suite. Or, you can code it yourself. Or, you can convince someone that the testing is necessary and they'll volunteer their time. For me, more testing would gain me nothing. I already test postgresql on a test box before throwing it into production. I test it for load, response, correctness, etc... and if I miss something, it's usually a pretty small issue, and it gets fixed fast. I'd much rather see time and effort go into the things they go into, like optimizing the query planner, in() with subselects, full text indexing, and many other things. There is a finite pool of hacker skill poured into Postgresql, and pouring more of it into testing means less gets poured into development, and right now, I've got all the testing I need, as do most of the developers and users I know. Open Source works because some scratches and itch. right now, you're the only one with an itch for more testing. If you don't scratch it, it likely won't get scratched any time soon. who knows, in a year, maybe someone else will get the itch and scratch it. But your arguments have been unconvincing, since the reality of Postgresql is that it is the absolutely most reliable database I know of, and has one of the fastest turnaround times for bug fixes when they do pop up. Does apache have a comprehensive test suite? Not that I know of. Neither does the Linux kernel or the BSD kernel. But, they all get the job done better than their commercial counterparts with far less headache. This discussion hasn't been a complete waste of time, but your arguments have bordered on insulting to those of us who currently DO the testing on our own machines. You've dismissed our testing out of hand on several occasions as insufficient, when at least we ARE testing postgresql, even if it doesn't meat up to your higher standards. If you want to raise the bar, then YOU get to raise it. ---(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] Physical Database Configuration
On 24 Jun 2003 at 14:48, Jonathan Bartlett wrote: I know the current method for specifying alternate drives for PG tables is by using symlinks. I had some ideas for simple ways to do this in PG code, but wanted to know if anyone was working on this right now. I'd hate to take the time to start messing with this if others were already on it. Well, correct solution is to implement tablespaces on which objects like databases, tables and indexes can be put. There was a long discussion on this and there was a tablespaces patch. It was agreed that tablespace as a set of directories would be a good point to start. I have no idea what is the status of that effort right now. You can search the archives or I hope this kicks a fresh discussion..:-) Please correct me if I am wrong. I am quoting from off my head.. not a trusted source.. Bye Shridhar -- Harriet's Dining Observation: In every restaurant, the hardness of the butter patsincreases in direct proportion to the softness of the bread. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [GENERAL] Physical Database Configuration
On 25 Jun 2003 at 12:30, Shridhar Daithankar wrote: On 25 Jun 2003 at 14:55, Christopher Kings-Lynne wrote: Well, correct solution is to implement tablespaces on which objects like databases, tables and indexes can be put. I have started working on tablespaces (to the extent that I am capable!), based not on the rejected patch, but on Jim's eventual syntax proposal that was never developed. For reference, http://archives.postgresql.org/pgsql-hackers/2002-09/msg01780.php Bye Shridhar -- Rules for Academic Deans: (1) HIDE (2) If they find you, LIE -- Father Damian C. Fandal ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
That seems too vague for TODO. We might as well add Make PostgreSQL faster. :-) 'K, can you add that one too? :) How about * Remove all bugs from the source. Can you put that in TODO ? :-) -- Kaare Rasmussen--Linux, spil,--Tlf:3816 2582 Kaki Datatshirts, merchandize Fax:3816 2501 Howitzvej 75 Åben 12.00-18.00Email: [EMAIL PROTECTED] 2000 FrederiksbergLørdag 12.00-16.00 Web: www.suse.dk ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PHP/PgSQL *and* libpq ...
Seems like we should also allow for a windows specific distribution of libpq as well. Robert Treat On Tuesday 24 June 2003 10:43 pm, Bruce Momjian wrote: Added to TODO: * Allow creation of a libpq-only tarball --- The Hermit Hacker wrote: Just a side bar to the whole thread about PHP/MySQL ... I realize that libpq is intwined with the backend right now, but if anyone could think of a way of at least adding a make target that would create a libpq.tar.gz distribution, I believe it would go a long way towards making it easier for ppl to add/compile in PgSQL support into PHP ... right now, to do so, you have to download an 8Meg file to get libpq ... if it could be reduced to a .5Meg tar.gz file: svr1# du -sk libpq 532 libpq it would be less onerous to download and add the support in ... ---(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] Two weeks to feature freeze
Kaare Rasmussen wrote: That seems too vague for TODO. We might as well add Make PostgreSQL faster. :-) 'K, can you add that one too? :) How about * Remove all bugs from the source. Can you put that in TODO ? :-) Change that into * Remove bugs from source code and get a patent on it. Should be a nobrainer (as in those guy's have no brains) considering that NetFlix even got a patent on DVD subscription rentals: http://slashdot.org/article.pl?sid=03/06/24/1458223mode=flattid=155tid=99 Jan -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] allowed user/db variables
Christopher Kings-Lynne wrote: I was considering adding this and the stuff Andreas requested to pg_settings (but not SHOW ALL or SHOW x unless people feel it's important to kept them consistent with pg_settings). Were the Red Hat guys going to do this? pg_settings would be fine for phpPgAdmin. Same for pgAdmin3. Regards, Andreas ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] PHP/PgSQL *and* libpq ...
On Wed, 25 Jun 2003 08:59:41 -0300 (ADT), Marc G. Fournier wrote:
On Wed, 25 Jun 2003, Robert Treat wrote:
Seems like we should also allow for a windows specific distribution of libpq
as well.
I thought that the win32 stuff was being included as part of the base
distribution? IF so, wouldn't such already be included in any
libpq.tar.gz we created? Is there a reason why we'd need a
libpq-win.tar.gz (assuming that that is what you are suggesting?) ... ?
i'm merely suggesting that a *.tar.gz may not be the best method of distribution
for windows users.
Robert Treat
On Tuesday 24 June 2003 10:43 pm, Bruce Momjian wrote:
Added to TODO:
* Allow creation of a libpq-only tarball
Robert treat
--
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL
---(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] Two weeks to feature freeze
Jan Wieck wrote: Change that into * Remove bugs from source code and get a patent on it. Should be a nobrainer (as in those guy's have no brains) considering that NetFlix even got a patent on DVD subscription rentals: http://slashdot.org/article.pl?sid=03/06/24/1458223mode=flattid=155tid=99 I'm applying for a patent on breathing now. The trick I found is reversing the direction of airflow in a regular way. The algorithm seems apparently simple, but it really makes the deal: Step 1. If your lungs are empty, let air flow into them through some air intake. This airflow might be ducted by some bronchial or additional tubing. Step 2 (optional) As soon as there's enough air in the lungs, you may decide to hold it there for a while. Some time limits might apply, please consult some specialist for details. Step 3 Press the air out of the lungs, using some muscles or externally applied force on the chest. The air will eventually escape through some body opening. Another patent I'll be applying for covers the use of nostrils for this purpose. Step 4 Restart the cycle at step 1. Regards and don't dare to try this without royalty fees! Andreas ---(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] Two weeks to feature freeze
On 25 Jun 2003 at 14:50, Andreas Pflug wrote: Jan Wieck wrote: Change that into * Remove bugs from source code and get a patent on it. Should be a nobrainer (as in those guy's have no brains) considering that NetFlix even got a patent on DVD subscription rentals: http://slashdot.org/article.pl?sid=03/06/24/1458223mode=flattid=155tid=99 I'm applying for a patent on breathing now. The trick I found is reversing the direction of airflow in a regular way. The algorithm seems apparently simple, but it really makes the deal: Step 1. If your lungs are empty, let air flow into them through some air intake. This airflow might be ducted by some bronchial or additional tubing. Step 2 (optional) As soon as there's enough air in the lungs, you may decide to hold it there for a while. Some time limits might apply, please consult some specialist for details. Step 3 Press the air out of the lungs, using some muscles or externally applied force on the chest. The air will eventually escape through some body opening. Another patent I'll be applying for covers the use of nostrils for this purpose. Step 4 Restart the cycle at step 1. Regards and don't dare to try this without royalty fees! Oops... I challenge it for prior art..:-) Bye Shridhar -- Gomme's Laws: (1) A backscratcher will always find new itches.(2) Time accelerates.(3) The weather at home improves as soon as you go away. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
Change that into * Remove bugs from source code and get a patent on it. Should be a nobrainer (as in those guy's have no brains) considering that NetFlix even got a patent on DVD subscription rentals: And for all the nice royalty money*, think about what can be done to PostgreSQL. Maybe even a test suite :-) * Or maybe the best step is to sue IBM or Microsoft. Then again, maybe not. Do they care about bug removal? ;-) -- Kaare Rasmussen--Linux, spil,--Tlf:3816 2582 Kaki Datatshirts, merchandize Fax:3816 2501 Howitzvej 75 Åben 12.00-18.00Email: [EMAIL PROTECTED] 2000 FrederiksbergLørdag 12.00-16.00 Web: www.suse.dk ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] timestamp bug?
Shouldn't we be detecting problems with the following (haven't seen
mention of it):
template1=# insert into b values('1000-12-01 23:23:23');
INSERT 555183 1
template1=# select * from b;
ERROR: Unable to format timestamp; internal coding error
Tested on reasonably recent CVS.
Mentioned on IRC.
Thanks,
Gavin
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] allowed user/db variables
I was considering adding this and the stuff Andreas requested to pg_settings (but not SHOW ALL or SHOW x unless people feel it's important to kept them consistent with pg_settings). Were the Red Hat guys going to do this? pg_settings would be fine for phpPgAdmin. Same for pgAdmin3. I agree with this plan also. I'm not sure if the RH guys had intended to get around to this or not --- it's not on their shortlist of stuff they need for their tools. The proposed patch from RH includes addition of descriptions to the variables' table entries in guc.c. It might make sense to include these as a column in pg_settings as well; but if we do then changing the view would have to wait till that patch is submitted and accepted. (I was offline yesterday but it doesn't look like anything's been done; I will remind 'em that feature freeze is hard upon us.) regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] a problem with index and user define type
Weiping He [EMAIL PROTECTED] writes: because the data type (UUID) is a struct, and the uuid_eq() function accept two pointer to the value of struct uuid, if make it IMMUTABLE, postgresql would think it should not try to run the function, but return the cached value instead when it get two same pointers input, No, it will not. Your claim above is entirely wrong; the fact that the datatype is pass-by-reference doesn't affect anything (unless you've failed to declare the datatype that way, but if so I'd not think it would work at all). regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] capturing and storing query statement with rules
Joe Conway [EMAIL PROTECTED] writes: I was thinking something similar. This exact question has come up at least three times in the last three months. I doubt we'd want a special keyword like CURRENT_QUERY, but maybe current_query()? Not unless you want to promote a quick debugging hack, not expected or required to work 100%, into a supported feature. I don't think debug_query_string can be relied on to always reflect what the system is doing, particularly not in the 3.0 protocol extended-query case. And how about when you're executing queries inside a function --- is it supposed to tell you about the most closely nested SQL query? I don't say this is not worth doing --- but I do say you are opening a larger can of worms than you probably think. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RServ patch to support multiple slaves (sorta)
Bruce Momjian [EMAIL PROTECTED] writes: Patch applied. Thanks. Michael A Nachbaur wrote: Attached is a patch that provides *VERY* limited support for multiple slave servers. I haven't tested it very well, so use at your own risk (and I recommend against using it in production). It sounded to me like that patch was intended for comment, not for application. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] capturing and storing query statement with
Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: I was thinking something similar. This exact question has come up at least three times in the last three months. I doubt we'd want a special keyword like CURRENT_QUERY, but maybe current_query()? Not unless you want to promote a quick debugging hack, not expected or required to work 100%, into a supported feature. I don't think debug_query_string can be relied on to always reflect what the system is doing, particularly not in the 3.0 protocol extended-query case. And how about when you're executing queries inside a function --- is it supposed to tell you about the most closely nested SQL query? I don't say this is not worth doing --- but I do say you are opening a larger can of worms than you probably think. Hmmm. Good points. This one may best wait for 7.5 at least. Does it make sense to turn it into a TODO? * promote debug_query_string into a documented, supported feature Anyone who *does* use the function from dblink, please be sure to report circumstances where dblink_current_query() returns something other than what you would expect. Thanks, Joe ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] RServ patch to support multiple slaves (sorta)
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Patch applied. Thanks. Michael A Nachbaur wrote: Attached is a patch that provides *VERY* limited support for multiple slave servers. I haven't tested it very well, so use at your own risk (and I recommend against using it in production). It sounded to me like that patch was intended for comment, not for application. He said it wasn't all he wanted to do with the code, but that it did work. With so few rserv patches, it seems like something we should get in, but maybe not? Other comments? I am not sure myself. -- 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/docs/faqs/FAQ.html
Re: [HACKERS] compile warnings
Joe Conway [EMAIL PROTECTED] writes: Other than these 4 warnings, I get a clean compile on Red Hat 9 and 8.0 systems. I see a couple other warnings when building on HPUX, but all are in ecpg: gcc -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/include -D_XOPEN_SOURCE_EXTENDED -g -c -o datetime.o datetime.c datetime.c: In function `PGTYPESdate_fmt_asc': datetime.c:240: warning: implicit declaration of function `snprintf' gcc -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/include -D_XOPEN_SOURCE_EXTENDED -g -c -o common.o common.c common.c: In function `pgtypes_fmt_replace': common.c:83: warning: implicit declaration of function `snprintf' gcc -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/include -D_XOPEN_SOURCE_EXTENDED -g -c -o dt_common.o dt_common.c This happens because the ecpg versions of these files ignore the Postgres convention that everything should include postgres.h or postgres_fe.h first. I have been planning to bug Michael about why that is; I think it will create a bunch of portability gotchas beyond this one. (Our code associated with 64-bit-offset file I/O, in particular, is known to break on some platforms when this rule is violated.) AFAIK the only way to get rid of the flex-related warnings is to not use yylineno. This seems like a good idea to me (when I got rid of yylineno in plpgsql's lexer, there were a number of benefits), but I don't have time to look at it ... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] [GENERAL] Physical Database Configuration
Christopher Kings-Lynne [EMAIL PROTECTED] writes: I have started working on tablespaces (to the extent that I am capable!), based not on the rejected patch, but on Jim's eventual syntax proposal that was never developed. Has anyone looked at the syntaxes used by other databases to control tablespaces (Oracle, DB2, etc)? I have no strong desire to slavishly follow Oracle, but it would be a shame to miss out on any good ideas. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] RServ patch to support multiple slaves (sorta)
On Wed, Jun 25, 2003 at 11:11:35AM -0400, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Patch applied. Thanks. Michael A Nachbaur wrote: Attached is a patch that provides *VERY* limited support for multiple slave servers. I haven't tested it very well, so use at your own risk (and I recommend against using it in production). It sounded to me like that patch was intended for comment, not for application. He said it wasn't all he wanted to do with the code, but that it did work. With so few rserv patches, it seems like something we should get in, but maybe not? Other comments? I am not sure myself. I don't remember the patch right now, but it seemed to me the patch didn't have anything to do with multiple slaves anyway... When was it posted? I can't find it in the archives... (it'd be nice to have the date of the original message in the attribution when you quote other people, that way it's much easier to find it in the archives) Some 2 years ago I wrote a patch for multiple slaves and it worked reasonably well... I wasn't too much in the Postgres world those days so I didn't submit it. If I can get to my CVS archive I'll extract it and post for review. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) A male gynecologist is like an auto mechanic who never owned a car. - Carrie Snow ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] ECPG compile error
/usr/local/bin/gmake -C ecpglib all gmake[4]: Entering directory `/usr/home/rbt/work/postgresql/pgsqlwarning/src/interfaces/ecpg/ecpglib' gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -DPIC -I../../../../src/interfaces/ecpg/include -I../../../../src/interfaces/libpq -I../../../../src/include -pthread -c -o misc.o misc.c -MMD misc.c: In function `ECPGset_informix_null': misc.c:272: `LONG_LONG_MIN' undeclared (first use in this function) misc.c:272: (Each undeclared identifier is reported only once misc.c:272: for each function it appears in.) misc.c: In function `ECPGis_informix_null': misc.c:330: `LONG_LONG_MIN' undeclared (first use in this function) gmake[4]: *** [misc.o] Error 1 gmake[4]: Leaving directory `/usr/home/rbt/work/postgresql/pgsqlwarning/src/interfaces/ecpg/ecpglib' -- 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] Physical Database Configuration
On Wed, Jun 25, 2003 at 11:34:14AM -0400, Tom Lane wrote: Has anyone looked at the syntaxes used by other databases to control tablespaces (Oracle, DB2, etc)? I have no strong desire to slavishly follow Oracle, but it would be a shame to miss out on any good ideas. DB2: CREATE TABLESPACE spacename ... ALTER TABLESPACE spacename ... RENAME TABLESPACE spacename TO newspacename CREATE TABLE name ... IN spacename [INDEX IN spacename] [LONG IN spacename] INDEX IN and LONG IN refer to the tablespace used to store the indices and the LOB values for that table, respectively. The create syntax revolves around nodegroups and such which are DB2 concepts i don't fully grok (i'm a programmer, not a DBA). But, yeah, those are really the only entrypoints. You can't create an index in a specific tablespace -- it will go wherever the table is set to put indices. I like the syntax (IN spacename), though. It's simple and straightforward. -johnn ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] compile warnings
On Wed, Jun 25, 2003 at 11:22:58AM -0400, Tom Lane wrote: I see a couple other warnings when building on HPUX, but all are in ecpg: The problem is that I do not have access to HP-UX. All my development and testing is done on Linux right now. And on my Debian system I get no warning at all. gcc -O1 -Wall -Wmissing-prototypes -Wmissing-declarations -g -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/include -D_XOPEN_SOURCE_EXTENDED -g -c -o datetime.o datetime.c datetime.c: In function `PGTYPESdate_fmt_asc': datetime.c:240: warning: implicit declaration of function `snprintf' This is strange. According to my man page snprintf is declared in stdio.h which indeed is included. Where does HP-UX declare snprintf? This happens because the ecpg versions of these files ignore the Postgres convention that everything should include postgres.h or postgres_fe.h first. I have been planning to bug Michael about why that is; I think it will create a bunch of portability gotchas beyond this one. (Our code associated with 64-bit-offset file I/O, in particular, is known to break on some platforms when this rule is violated.) pgtypes is supposed to live alone and outside of postgresql. I just checked and found one file including postgres_fe.h. I will change this as it does not really need to include it. This would be different if we found a way to use pgtypes from the backend instead of implementing the stuff twice. But I'm still not sure how high the performance penalty will be. As for yylineno, it is used in ecpg, yes. Does anyone know how to get rid of it and still get the correct line number? Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ss_family in hba.c
On Tue, Jun 24, 2003 at 04:10:13PM -0400, Jason Tishler wrote: Bruce, On Tue, Jun 24, 2003 at 03:04:05PM -0400, Bruce Momjian wrote: Kurt Roeckx wrote: All that probably needed to change for cygwin was to no longer use sa_family_t in the getaddrinfo.c. But Jason reported he needed that typedef for sa_family_t. Jason, is that accurate. Yes. If you remove the Cygwin typedef in pqcomm.h, does the compile fail? It seems that struct sockaddr_storage is defined in winsock2.h, but that is only included in the win32 port. Maybe the right solution is the include that winsock2.h instead (through windows.h?) And make sure configure also includes it when doing the checks. The headers even seem to define struct sockaddr_in6, getaddrinfo and getnameinfo, so I wonder if cygwin supports ipv6 or not. Kurt ---(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] ECPG compile error
On Wed, Jun 25, 2003 at 11:51:47AM -0400, Rod Taylor wrote: misc.c: In function `ECPGset_informix_null': misc.c:272: `LONG_LONG_MIN' undeclared (first use in this function) misc.c:272: (Each undeclared identifier is reported only once misc.c:272: for each function it appears in.) misc.c: In function `ECPGis_informix_null': misc.c:330: `LONG_LONG_MIN' undeclared (first use in this function) Geez, platform independeny is a major headache. :-) It seems my system automatically included limits.h. Other appear to not do this. I already committed an update but I'm not sure you have the version that does. Anyway, if you have and it appears you also have HAVE_LONG_LONG_INT_64 defined, which header file does provide the approprioate constants and how is it named? It seems INT_MIN etc. are there. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] ECPG compile error
Anyway, if you have and it appears you also have HAVE_LONG_LONG_INT_64 defined, which header file does provide the approprioate constants and how is it named? It seems INT_MIN etc. are there. /usr/include/machine/limits.h seems to have INT_MIN, etc. in them. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] compile warnings
Michael Meskes [EMAIL PROTECTED] writes: This is strange. According to my man page snprintf is declared in stdio.h which indeed is included. Where does HP-UX declare snprintf? It doesn't. Were you including our standard config headers, you'd get our standard workarounds for missing declarations. Since you are not, you are *on your own* to deal with all of the same portability issues that we've so painfully resolved over the years. Does that sound like a good plan to you? This happens because the ecpg versions of these files ignore the Postgres convention that everything should include postgres.h or postgres_fe.h first. pgtypes is supposed to live alone and outside of postgresql. More so than, say, libpq? I don't think this is a real good idea at all. As for yylineno, it is used in ecpg, yes. Does anyone know how to get rid of it and still get the correct line number? You could roll your own, the way plpgsql's lexer now does. I know it sounds like a pain, but it really does fix a number of problems (I think the specific thing that persuaded me to do it in plpgsql was to keep the lexer from failing on very long string constants). Check CVS to see what I did in this patch: 2003-05-05 12:46 tgl * src/pl/plpgsql/src/: gram.y, pl_comp.c, plpgsql.h, scan.l: Alter plpgsql's lexer so that yylineno and yymore are not used. This avoids 'input buffer overflow' failure on long literals, improves performance, gives the right answer for line position in functions containing multiline literals, suppresses annoying compiler warnings, and generally is so much better I wonder why we didn't do it before. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] ECPG compile error
Anyway, if you have and it appears you also have HAVE_LONG_LONG_INT_64 defined, which header file does provide the approprioate constants and how is it named? It seems INT_MIN etc. are there. Sorry, limits.h includes machine/limits.h. Which (after a fresh cvsup), I have your earlier fix. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
[HACKERS] still getting ecpg compile failures
I saw a thread on this earlier, but I just cvsup'd (and `cvs up`, `make clean`, `make all`) and I'm getting: make[4]: Leaving directory `/opt/src/pgsql/src/interfaces/ecpg/include' make -C pgtypeslib all make[4]: Entering directory `/opt/src/pgsql/src/interfaces/ecpg/pgtypeslib' gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -fpic -I../../../../src/interfaces/ecpg/include -I../../../../src/include/utils -I../../../../src/include -g -c -o numeric.o numeric.c -MMD numeric.c: In function `set_var_from_str': numeric.c:152: `bool' undeclared (first use in this function) numeric.c:152: (Each undeclared identifier is reported only once numeric.c:152: for each function it appears in.) numeric.c:152: parse error before have_dp numeric.c:184: `have_dp' undeclared (first use in this function) numeric.c:184: `TRUE' undeclared (first use in this function) make[4]: *** [numeric.o] Error 1 make[4]: Leaving directory `/opt/src/pgsql/src/interfaces/ecpg/pgtypeslib' Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] Updating psql for features of new FE/BE protocol
There are a number of things that need to be done in psql before feature freeze. Any comments on the following points? * We need a client-side autocommit-off implementation to substitute for the one removed from the server. I am inclined to create a new psql backslash command: \autocommit on traditional handling of transactions \autocommit off force BEGIN before any user command that's not already in a transaction \autocommit with no arg, show current state An alternative to creating a new command is to define a special variable in psql, whereupon the above three would instead be rendered \set AUTOCOMMIT on \set AUTOCOMMIT off \echo :AUTOCOMMIT The first choice seems less verbose to me, but if anyone wants to make a case for the second, I'm open to it. Note that either of these could be put in ~/.psqlrc if someone wants autocommit off as their default. * Since libpq now keeps track of transaction state, it would be a simple matter to add a prompt-string % construct to show something that indicates the state (with possible values idle, in transaction, in failed transaction). Any thoughts about exactly what this ought to look like? I prototyped it with code that showed 'I', 'T', or 'E' but I suspect that non-alphabetic characters would be better, since they wouldn't look like part of a database name or other things you might put in the prompt. BTW, both of the above features will work against pre-7.4 servers, with the exception that a 7.3 server running with server-side autocommit off will confuse libpq's tracking of transaction state. Not sure how important that really is, given that we don't recommend running psql against servers of different versions. * I plan to get rid of psql's startup-time query to find out if you are superuser, and instead let the '#' vs '' prompt be driven through another ParameterStatus variable, per a proposal I made awhile ago. (If anyone can propose a better name for the GUC variable than am_superuser, let's hear it.) If I remove the startup query entirely, then when talking to pre-7.4 servers the prompt would always show ''. It'd be possible to continue to issue the query against pre-7.4 servers only, but is it worth the trouble? Again, we don't go to much trouble to make psql work 100% with old servers. * We can get rid of psql's LO_TRANSACTION variable, or at least make the behavior more robust, now that psql can see the current transaction state. Two cases are pretty obvious: if idle, then start and end our own transaction around the LO operation. If in a transaction, do not issue BEGIN or COMMIT, but just use that transaction. The third case is what to do if in a failed transaction. You could argue that the LO operation should be allowed to fail as well. Alternatively, we could roll back the failed xact and then proceed as in the idle case. Anyone have a good case to make for either choice? Should we redefine LO_TRANSACTION to allow both choices to be supported? Does anyone feel that the existing LO_TRANSACTION behaviors of forced-rollback or forced-commit of open transactions should continue to be supported? * \encoding can be driven from ParameterStatus too, thus making it more robust (it will correctly show an encoding set via a SET command). Opinions welcome ... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] still getting ecpg compile failures
On Wed, Jun 25, 2003 at 10:36:09AM -0700, Joe Conway wrote: I saw a thread on this earlier, but I just cvsup'd (and `cvs up`, `make clean`, `make all`) and I'm getting: Not really surprising since I committed just one file but changed seven. I guess I better stop working on this for today. Michael -- Michael Meskes Email: Michael at Fam-Meskes dot De ICQ: 179140304, AIM: michaelmeskes, Jabber: [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(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] Physical Database Configuration
On Wednesday, June 25, 2003, at 12:10 PM, johnn wrote: On Wed, Jun 25, 2003 at 11:34:14AM -0400, Tom Lane wrote: Has anyone looked at the syntaxes used by other databases to control tablespaces (Oracle, DB2, etc)? I have no strong desire to slavishly follow Oracle, but it would be a shame to miss out on any good ideas. DB2: CREATE TABLESPACE spacename ... ALTER TABLESPACE spacename ... RENAME TABLESPACE spacename TO newspacename CREATE TABLE name ... IN spacename [INDEX IN spacename] [LONG IN spacename] INDEX IN and LONG IN refer to the tablespace used to store the indices and the LOB values for that table, respectively. The create syntax revolves around nodegroups and such which are DB2 concepts i don't fully grok (i'm a programmer, not a DBA). But, yeah, those are really the only entrypoints. You can't create an index in a specific tablespace -- it will go wherever the table is set to put indices. I like the syntax (IN spacename), though. It's simple and straightforward. Oracle 8 examples: CREATE TABLE name(dud INTEGER) storage 8M next 4M pctincrease 0 minextents 1 maxextents 200 tablespace TSNAME; where storage, next, pctincrease, minextents, and maxentents are table space usage granularity requests. CREATE TABLESPACE TSNAME datafile '/path/file.dbf' size 100M, '/another/file.dbf' size 50M default storage (initial 1M next 1M pctincrease 0 maxentents 249); where each comma-delimited item is an extent- simply put, a block which Oracle is allowed to use for storage. ALTER TABLESPACE TEMP ...; allows for arbitrary placement of temporary table storage (higher-speed area?) ALTER TABLESPACE TSNAME default storage (...); changes settings for tablespace. ALTER TABLESPACE TSNAME coalesce; more extent optimization granularlity. CREATE ROLLBACK SEGMENT R1 tablespace TSNAME2 storage (...); which allocates space for a rollback area. ALTER ROLLBACK SEGMENT R1 offline/online; allows for cleanup of rollback segment's area. CREATE TABLE name(dud INTEGER PRIMARY KEY USING INDEX ); allows for pointing an index to a tablespace. CREATE INDEX ind ON table(col) global/local partition by range(col) (partition PART1 values less than (11) tablespace TS1, partition PART2 values less than (21) tablespace TS2, partition PART3 values less than (MAXVALUE) tablespace TS3); allows for a partioned index across tablespaces, but whose grammar setup could use some work. ALTER TABLE table MODIFY PARTITION part1storage (...) logging/nologging MOVE PARTITION ADD PARTITION part1 values less than (...) DROP PARTITION TRUNCATE PARTITION SPLIT PARTITION ... INTO ... EXCHANGE PARTITION a nasty alter table command related to partitions (a tablespace can have multiple partitions). I post this just so there a flavor of how many optimization options are available in Oracle 8. Personally, I would prefer not to have so many options but this listing should help folks so they don't paint themselves into a corner while coding on the tablespaces. All examples courtesy of Oracle 8: Advanced Tuning and Administration, Aronoff, Eyal, et al. ASIN: 0078822416 (c) 1998. (perhaps a little outdated) AgentM [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] Feature freeze and the great elog changeover
I had originally planned to spend the next week editing all the elog() calls in the backend to convert them to ereport() format where helpful, add SQLSTATE values, and update wording to match the style guidelines that were agreed to awhile back. However, it looks like the same reasons that were holding me back still apply: any wholesale editing will likely break unapplied patches, plus I'll have to go back through the code when those patches do get applied. With folk scrambling to get last-minute stuff done before feature freeze, these are not good side-effects. What I'd like to do instead is try to get the editing done during the interval between feature freeze and the start of beta (which we've already agreed is July 1 - July 15). I do not feel that this violates the spirit of feature freeze, but does anyone want to object to that plan? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
Jan, There have been a good number of examples where the one who raised an issue isn't just of the format to implement it. So someone else jumped in and did it instead. I don't need to pick any particular samples, you know that it happened a few times. Sure. But in those cases, the fix/feature was something that the consensus on -Hackers agreed needed to be done, someday. Putting those items on the TODO was an acknowledgement of that decision, even though they won't be implemented until we aquire more contributors. As an example, the various PL/pgSQL enhancements which Patrick and I pushed onto the TODO list, which are still features in search of a programmer. That took, as I recall, about a month of lobbying on this list, which required me to prove a) how our current PL/pgSQL was weak, and b) how the improvements would benefit the project overall, and c) how many people were interested in the improvements. There are 3 problems with Dann's proposal that have caused it to be shot down in flames instead of being put on the TODO list: 1) Most people on this list ... particularly, most contributors ... do not agree with Dann's proposal. This is in no little part due to Dann's lack of material evidence for his case. 2) Dann has a particularly abrasive and insulting communication style that hasn't helped his case any, either. 3) Dann is proposing not just a feature but sweeping changes to the way our commmunity works, despite having been a member of this community for about 3 weeks total. As such, this discussion is an example of the Open Source Process (tm) working correctly. Someone brought up a proposal, it was challenged, they were not able to defend the proposal, and it was voted down. -- Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] Physical Database Configuration
On Wed, 25 Jun 2003, Tom Lane wrote: Has anyone looked at the syntaxes used by other databases to control tablespaces (Oracle, DB2, etc)? I have no strong desire to slavishly follow Oracle, but it would be a shame to miss out on any good ideas. Informix is pretty bad. First, you use an external app to create the tablespace (known as a dbspace to informix). Lets call the new one 'newspace'. (the syntax is onspaces -c -d newspace -p /path/to/space -s size_in_kb -o offset_in_file I'll cry if we have something liek that in pg) then to 'use' the space: create table|index ... in newspace There's a bizzare syntax for copying a table from one space to another, but it is mostly useless since it runs in a transaction and if you have a big table.. well you get the idea. Where it gets more interesting is table fragments. Informix is able to fragment a table based on a few different criteria. Each fragment goes in a separate dbspace and the idea is the planner is smart enough to realize that it can parellelize seq scans and various other IO operations... but given the nature of postgres I don't think we could build something like that... (for the record, the fragment types are round robin and expression. You can fragment based on a limited-edition where clause.. ) -- Jeff Trout [EMAIL PROTECTED] http://www.jefftrout.com/ http://www.stuarthamm.net/ ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
Josh Berkus [EMAIL PROTECTED] writes: 3) Dann is proposing not just a feature but sweeping changes to the way our commmunity works, despite having been a member of this community for about 3 weeks total. In Dann's defense, I didn't think I heard him proposing that we get rid of our existing testing methods, but rather that we see if we can't supplement them with something more formal. This strikes me as a perfectly reasonable proposal. However, he hasn't succeeded in convincing anyone else to put their time into it (for reasons that are also perfectly reasonable, namely that we find that our existing methods do pretty well, and we don't have the manpower to create a large formal testing structure ... even if we thought it would repay the effort, which many of us doubt). So it's his itch to scratch, or not. Unless there's something more profitable to be said on the subject, could we drop the thread? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] Physical Database Configuration
On Wed, Jun 25, 2003 at 10:30:31AM -0500, Andrew Dunstan wrote: DB2 looks good. I have horrid, horrid memories of wrestling with the Oracle extent madness. I do think that it's worth providing additional access points to tablespaces, though. That is, it would make sense to me to allow CREATE INDEX indexname IN spacename, instead of attaching an indexspace to a table. This is especially true with postgresql, since i've seen more than one proposal for multi-table indices. If we're spacing indices based on the table, it's unclear where a given multi-table index should go. It would also allow for other flexibilities, like putting join indices (on foreign keys) in one tablespace, with indices for aggregation or sorting in another tablespace. So, my vote, as a non-code-contributing member, would be for a DB2-style syntax, without the INDEX IN and LONG IN extensions, but with the ability to put indices explicitly into a tablespace. -johnn ---(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] Updating psql for features of new FE/BE protocol
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Since libpq now keeps track of transaction state, it would be a simple matter to add a prompt-string % construct to show something that indicates the state greg= SELECT 'I am idle'; greg=* SELECT 'I am in a transaction'; greg=! SELECT 'I am in a failed transaction, please save me.'; Not sure how important that really is, given that we don't recommend running psql against servers of different versions. We also do not check the version or throw a warning on a mismatched version, something I think it may be time to reevaluate. Everything else sounds good. - -- Greg Sabino Mullane [EMAIL PROTECTED] PGP Key: 0x14964AC8 200306251455 -BEGIN PGP SIGNATURE- Comment: http://www.turnstep.com/pgp.html iD8DBQE++fzOvJuQZxSWSsgRApyZAKDQbTVR6u6sFGgl4FWgYy23VQ/U8ACfTHyU FGkdjEg6CCIsOQo9NSYen8g= =9fFL -END PGP SIGNATURE- ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] [GENERAL] Physical Database Configuration
DB2 looks good. I have horrid, horrid memories of wrestling with the Oracle extent madness. I think Oracle's extents came from their fixed size data file legacy, in 9i the extent limits appear to be completely overridable and sometimes even ignored, such as the next extent size. I agree that the 128 extent limit was a pain, and the default for each new extent to be larger than the previous one created many problems. Oracle also took physical abstraction one level beyond 'tablespaces'. I think if each tablespace pointed to a specific directory, that'd be sufficient for me. And since I envision the tablespace as an attribute of the table that should take care of the 1GB file rollover issue, as the rollover would occur in the same directory as the first file. Without having delved into the code yet, setting up entries for user default tablespaces and system information is probably at least as much work as getting a tablespace to point to a specific directory for the purposes of opening or creating files for an object. My personal preference would be to have four tablespaces predefined as part of a new database, though initially they could all point to the same place: SYSTEM USER TEMP INDEXES What about the concepts of a 'read-only' tablespace, or taking tablespaces offline? -- Mike Nolan ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Updating psql for features of new FE/BE protocol
Tom Lane wrote: There are a number of things that need to be done in psql before feature freeze. Any comments on the following points? * We need a client-side autocommit-off implementation to substitute for the one removed from the server. I am inclined to create a new psql backslash command: \autocommit on traditional handling of transactions \autocommit off force BEGIN before any user command that's not already in a transaction \autocommit with no arg, show current state An alternative to creating a new command is to define a special variable in psql, whereupon the above three would instead be rendered \set AUTOCOMMIT on \set AUTOCOMMIT off \echo :AUTOCOMMIT The first choice seems less verbose to me, but if anyone wants to make a case for the second, I'm open to it. Note that either of these could be put in ~/.psqlrc if someone wants autocommit off as their default. I thought we were trying to get away from multi-letter backslash variables like \connect. I think we should use \set,\echo, though of course, those are multi-letter too, so maybe it isn't an issue. I just find \df and \df_and_more_letters_that_make_a_word to just be weird. * Since libpq now keeps track of transaction state, it would be a simple matter to add a prompt-string % construct to show something that indicates the state (with possible values idle, in transaction, in failed transaction). Any thoughts about exactly what this ought to look like? I prototyped it with code that showed 'I', 'T', or 'E' but I suspect that non-alphabetic characters would be better, since they wouldn't look like part of a database name or other things you might put in the prompt. BTW, both of the above features will work against pre-7.4 servers, with the exception that a 7.3 server running with server-side autocommit off will confuse libpq's tracking of transaction state. Not sure how important that really is, given that we don't recommend running psql against servers of different versions. Don't worry about old servers in this regard. * I plan to get rid of psql's startup-time query to find out if you are superuser, and instead let the '#' vs '' prompt be driven through another ParameterStatus variable, per a proposal I made awhile ago. (If anyone can propose a better name for the GUC variable than am_superuser, let's I think 'is_superuser' is more appropriate. -- 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 7: don't forget to increase your free space map settings
Re: [HACKERS] Feature freeze and the great elog changeover
Good idea. This is similar to the pgindent run, though that usually happens just _before_ beta. --- Tom Lane wrote: I had originally planned to spend the next week editing all the elog() calls in the backend to convert them to ereport() format where helpful, add SQLSTATE values, and update wording to match the style guidelines that were agreed to awhile back. However, it looks like the same reasons that were holding me back still apply: any wholesale editing will likely break unapplied patches, plus I'll have to go back through the code when those patches do get applied. With folk scrambling to get last-minute stuff done before feature freeze, these are not good side-effects. What I'd like to do instead is try to get the editing done during the interval between feature freeze and the start of beta (which we've already agreed is July 1 - July 15). I do not feel that this violates the spirit of feature freeze, but does anyone want to object to that plan? regards, tom lane ---(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] Updating psql for features of new FE/BE protocol
[EMAIL PROTECTED] writes: Not sure how important that really is, given that we don't recommend running psql against servers of different versions. We also do not check the version or throw a warning on a mismatched version, something I think it may be time to reevaluate. It would be easy (and essentially free, since libpq already gets the info) to add such a notice to psql startup. How do other people feel about it? How would you word the notice exactly? psql: server version is FOO, psql version is BAR, some things may not work seems awfully vague, but I doubt we can be much more specific ... regards, tom lane ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [HACKERS] Two weeks to feature freeze
Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] writes: 3) Dann is proposing not just a feature but sweeping changes to the way our commmunity works, despite having been a member of this community for about 3 weeks total. In Dann's defense, I didn't think I heard him proposing that we get rid of our existing testing methods, but rather that we see if we can't supplement them with something more formal. This strikes me as a perfectly reasonable proposal. However, he hasn't succeeded in convincing anyone else to put their time into it (for reasons that are also perfectly reasonable, namely that we find that our existing methods do pretty well, and we don't have the manpower to create a large formal testing structure ... even if we thought it would repay the effort, which many of us doubt). So it's his itch to scratch, or not. Unless there's something more profitable to be said on the subject, could we drop the thread? One thing that came out of the thread is the fact that many people who use PostgreSQL do testing in many different ways, and that much of the stability of PostgreSQL can be attributed to that. It occurs to me that there may be (perhaps) a lot of duplication of effort there that could be reduced a bit. So...would it make sense to create a gborg project to which people who have written their own test suites can contribute whatever code and data they feel comfortable releasing? As a gborg project, it would be separate from the main PG distribution and would thus have no impact on the build process or anything like that. But at the same time, if there are any ideas on testing that people have had, they could be shared with others through that mechanism. And any tests which prove to be particularly useful could make their way into the PG distribution if people here wish. Of course, like anything else this could be a bad (or perhaps redundant) idea. :-) -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] RServ patch to support multiple slaves (sorta)
On Wednesday 25 June 2003 08:42 am, Alvaro Herrera wrote: On Wed, Jun 25, 2003 at 11:11:35AM -0400, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Patch applied. Thanks. Michael A Nachbaur wrote: Attached is a patch that provides *VERY* limited support for multiple slave servers. I haven't tested it very well, so use at your own risk (and I recommend against using it in production). It sounded to me like that patch was intended for comment, not for application. Yes, this was my original intent. If anyone else thought it was worthy enough to go into CVS, then great, but mainly I wanted a few more pairs of eyes to look it over. He said it wasn't all he wanted to do with the code, but that it did work. With so few rserv patches, it seems like something we should get in, but maybe not? Other comments? I am not sure myself. I don't remember the patch right now, but it seemed to me the patch didn't have anything to do with multiple slaves anyway... When was it posted? I can't find it in the archives... (it'd be nice to have the date of the original message in the attribution when you quote other people, that way it's much easier to find it in the archives) All my patch does is allow you to limit what tables you replicate from a slave. In this way, SlaveA can replicate tables X, Y and Z, while SlaveB can replicate tables M, N and O. I have a single master database, and different authentication databases at key areas of my infrastructure (mail authentication, web server configuration, etc). I was getting errors when trying to replicate SlaveA just after adding SlaveB, because the necessary tables didn't exist on SlaveA. Some 2 years ago I wrote a patch for multiple slaves and it worked reasonably well... I wasn't too much in the Postgres world those days so I didn't submit it. If I can get to my CVS archive I'll extract it and post for review. That'd be great. My patch, like I said in my original post (06/19/2003 07:36pm PST), is just a beginning, and I'm not even 100% sure it'll work reliably. Although I'm an experienced Perl programmer, I'm not as familar with PostgreSQL's internals as I'd like to be (e.g. I tread lightly when it comes to the pg_* tables). If someone else has better support, I'd much rather a) take the code and run, and b) not have to do the same myself since I have too many items on my task list as it is. -- Michael A Nachbaur [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Feature freeze and the great elog changeover
Bruce Momjian [EMAIL PROTECTED] writes: Good idea. This is similar to the pgindent run, though that usually happens just _before_ beta. Right. It still should; I'd recommend we do that after I finish the error message edits. I think at least one person had volunteered to help with the editing; that might be a good thing if they're still willing. There's something upwards of 4000 elog calls to be looked at :-( regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Feature freeze and the great elog changeover
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Good idea. This is similar to the pgindent run, though that usually happens just _before_ beta. Right. It still should; I'd recommend we do that after I finish the error message edits. I think at least one person had volunteered to help with the editing; that might be a good thing if they're still willing. There's something upwards of 4000 elog calls to be looked at :-( Do we get error numbers with that? :-) -- 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] Two weeks to feature freeze
Kevin, So...would it make sense to create a gborg project to which people who have written their own test suites can contribute whatever code and data they feel comfortable releasing? As a gborg project, it would be separate from the main PG distribution and would thus have no impact on the build process or anything like that. But at the same time, if there are any ideas on testing that people have had, they could be shared with others through that mechanism. +1 -Josh ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [GENERAL] Physical Database Configuration
johnn wrote: On Wed, Jun 25, 2003 at 10:30:31AM -0500, Andrew Dunstan wrote: DB2 looks good. I have horrid, horrid memories of wrestling with the Oracle extent madness. I do think that it's worth providing additional access points to tablespaces, though. That is, it would make sense to me to allow CREATE INDEX indexname IN spacename, instead of attaching an indexspace to a table. This is especially true with postgresql, since i've seen more than one proposal for multi-table indices. If we're spacing indices based on the table, it's unclear where a given multi-table index should go. It would also allow for other flexibilities, like putting join indices (on foreign keys) in one tablespace, with indices for aggregation or sorting in another tablespace. I wonder why an index spanning multiple tables should be stored in a different location than the tables itself. If we're talking about derived tables, all data/index must be available at the same time to be meaningful, so why not restrict them to the same tablespace? This sounds like more flexibility than really useful to me. The philosophy of pgsql is to let the os and the io system distribute the load over disks and other resources, not to do it in the backend. That's why we need much less organizational effort than other systems that try to implement everything themselves, on raw devices etc. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Feature freeze and the great elog changeover
Bruce Momjian [EMAIL PROTECTED] writes: I think at least one person had volunteered to help with the editing; that might be a good thing if they're still willing. There's something upwards of 4000 elog calls to be looked at :-( Do we get error numbers with that? :-) That is the point ... I'd not really be bothering otherwise ... regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Updating psql for features of new FE/BE protocol
From: Tom Lane [EMAIL PROTECTED] It would be easy (and essentially free, since libpq already gets the info) to add such a notice to psql startup. How do other people feel about it? How would you word the notice exactly? psql: server version is FOO, psql version is BAR, some things may not work seems awfully vague, but I doubt we can be much more specific ... Do we have any documentation on psql compatibility across versions? If so, we could refer the user to that document. Might be nice to know that most \commands will not work, but ad hoc queries will be fine. Matthew ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Feature freeze and the great elog changeover
Lots of hardcoded english... is i8n something which gets raised often, or is it lingue franca enough that people don't care? (Since all the messages are going to be looked at anyways...) Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I think at least one person had volunteered to help with the editing; that might be a good thing if they're still willing. There's something upwards of 4000 elog calls to be looked at :-( Do we get error numbers with that? :-) That is the point ... I'd not really be bothering otherwise ... -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(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] Feature freeze and the great elog changeover
Paul Ramsey [EMAIL PROTECTED] writes: Lots of hardcoded english... What makes you think it's hardcoded? We've had internationalization support for awhile. (One of the results I'd like to accomplish in this pass is to reduce the number of junk messages that translators need to look at, by merging near-duplicates and suppressing .po entries for internal-can't-happen errors.) 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] Feature freeze and the great elog changeover
Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: Lots of hardcoded english... What makes you think it's hardcoded? We've had internationalization support for awhile. (One of the results I'd like to accomplish in this pass is to reduce the number of junk messages that translators need to look at, by merging near-duplicates and suppressing .po entries for internal-can't-happen errors.) Ignorance on my part, probably. You mentioned elog() so I grepped for it and found lots of this stuff: elog(FATAL, data directory %s was not found, checkdir) elog(FATAL, could not read permissions of directory %s: %m, checkdir); I am probably just misunderstanding something. P. -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Feature freeze and the great elog changeover
Paul Ramsey [EMAIL PROTECTED] writes: I am probably just misunderstanding something. See http://candle.pha.pa.us/main/writings/pgsql/sgml/nls.html regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Updating psql for features of new FE/BE protocol
Is it too late to suggest that there be a way to have output displayed on screen AND output to a file? I've got my Oracle systems set up so that all sqlplus sessions do this, complete with using the process or session number as part of the output file name so each is unique. This gives me a running record of what I did when, which saves me a LOT of time if I want to view the results of some query I ran last week. I can delete or zip up files if I get short on disk space space -- Mike Nolan ---(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] Feature freeze and the great elog changeover
On Wed, 25 Jun 2003, Paul Ramsey wrote: Ignorance on my part, probably. You mentioned elog() so I grepped for it and found lots of this stuff: elog(FATAL, data directory %s was not found, checkdir) elog(FATAL, could not read permissions of directory %s: %m, checkdir); I am probably just misunderstanding something. It's taken care of by the gettext system. One thing that I would like to see in the future (but probably wont for many years still) is a log file that is saved in a format like data directory %s was not found, /usr/ where you can view the log with some (gui och command-line) tool that translates it when you look at it. Then anyone can look at the log using their language and you don't have to decide one one language when you start the server. Maybe something for postgresql X. -- /Dennis ---(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] Updating psql for features of new FE/BE protocol
[EMAIL PROTECTED] writes: Is it too late to suggest that there be a way to have output displayed on screen AND output to a file? tee perhaps? This is irrelevant to what I'm doing, in any case, and it's not an itch I feel personally. Work on it yourself if you want it ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] RServ patch to support multiple slaves (sorta)
OK, I have backed out this patch. Hopefully we can get a more complete patch sometime. --- Michael A Nachbaur wrote: On Wednesday 25 June 2003 08:42 am, Alvaro Herrera wrote: On Wed, Jun 25, 2003 at 11:11:35AM -0400, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Patch applied. Thanks. Michael A Nachbaur wrote: Attached is a patch that provides *VERY* limited support for multiple slave servers. I haven't tested it very well, so use at your own risk (and I recommend against using it in production). It sounded to me like that patch was intended for comment, not for application. Yes, this was my original intent. If anyone else thought it was worthy enough to go into CVS, then great, but mainly I wanted a few more pairs of eyes to look it over. He said it wasn't all he wanted to do with the code, but that it did work. With so few rserv patches, it seems like something we should get in, but maybe not? Other comments? I am not sure myself. I don't remember the patch right now, but it seemed to me the patch didn't have anything to do with multiple slaves anyway... When was it posted? I can't find it in the archives... (it'd be nice to have the date of the original message in the attribution when you quote other people, that way it's much easier to find it in the archives) All my patch does is allow you to limit what tables you replicate from a slave. In this way, SlaveA can replicate tables X, Y and Z, while SlaveB can replicate tables M, N and O. I have a single master database, and different authentication databases at key areas of my infrastructure (mail authentication, web server configuration, etc). I was getting errors when trying to replicate SlaveA just after adding SlaveB, because the necessary tables didn't exist on SlaveA. Some 2 years ago I wrote a patch for multiple slaves and it worked reasonably well... I wasn't too much in the Postgres world those days so I didn't submit it. If I can get to my CVS archive I'll extract it and post for review. That'd be great. My patch, like I said in my original post (06/19/2003 07:36pm PST), is just a beginning, and I'm not even 100% sure it'll work reliably. Although I'm an experienced Perl programmer, I'm not as familar with PostgreSQL's internals as I'd like to be (e.g. I tread lightly when it comes to the pg_* tables). If someone else has better support, I'd much rather a) take the code and run, and b) not have to do the same myself since I have too many items on my task list as it is. -- Michael A Nachbaur [EMAIL PROTECTED] -- 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 ? config.log ? GNUmakefile ? config.status ? src/log ? src/Makefile.global ? src/Makefile.custom ? src/backend/utils/mb/conversion_procs/conversion_create.sql ? src/backend/utils/mb/conversion_procs/ascii_and_mic/libascii_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/cyrillic_and_mic/libcyrillic_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_cn_and_mic/libeuc_cn_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_jp_and_sjis/libeuc_jp_and_sjis.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_kr_and_mic/libeuc_kr_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/euc_tw_and_big5/libeuc_tw_and_big5.so.0.0 ? src/backend/utils/mb/conversion_procs/latin2_and_win1250/liblatin2_and_win1250.so.0.0 ? src/backend/utils/mb/conversion_procs/latin_and_mic/liblatin_and_mic.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_ascii/libutf8_and_ascii.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_big5/libutf8_and_big5.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_cyrillic/libutf8_and_cyrillic.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_cn/libutf8_and_euc_cn.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_jp/libutf8_and_euc_jp.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_kr/libutf8_and_euc_kr.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_euc_tw/libutf8_and_euc_tw.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_gb18030/libutf8_and_gb18030.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_gbk/libutf8_and_gbk.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859/libutf8_and_iso8859.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_iso8859_1/libutf8_and_iso8859_1.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_johab/libutf8_and_johab.so.0.0 ? src/backend/utils/mb/conversion_procs/utf8_and_sjis/libutf8_and_sjis.so.0.0 ?
Re: [HACKERS] [GENERAL] capturing and storing query statement with
Added to TODO: * Promote debug_query_string into a server-side function current_query() --- Joe Conway wrote: Tom Lane wrote: Joe Conway [EMAIL PROTECTED] writes: I was thinking something similar. This exact question has come up at least three times in the last three months. I doubt we'd want a special keyword like CURRENT_QUERY, but maybe current_query()? Not unless you want to promote a quick debugging hack, not expected or required to work 100%, into a supported feature. I don't think debug_query_string can be relied on to always reflect what the system is doing, particularly not in the 3.0 protocol extended-query case. And how about when you're executing queries inside a function --- is it supposed to tell you about the most closely nested SQL query? I don't say this is not worth doing --- but I do say you are opening a larger can of worms than you probably think. Hmmm. Good points. This one may best wait for 7.5 at least. Does it make sense to turn it into a TODO? * promote debug_query_string into a documented, supported feature Anyone who *does* use the function from dblink, please be sure to report circumstances where dblink_current_query() returns something other than what you would expect. Thanks, Joe ---(end of broadcast)--- TIP 8: explain analyze is your friend -- 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 8: explain analyze is your friend
Re: [HACKERS] RServ patch to support multiple slaves (sorta)
On Thursday 19 June 2003 07:36 pm, Michael A Nachbaur wrote: Attached is a patch that provides *VERY* limited support for multiple slave servers. I haven't tested it very well, so use at your own risk (and I recommend against using it in production). snip Okay, I just did some more testing, and found out that my code actually doesn't work. Consider the attached test case (if run with -delete, it will delete the master, slavea - slavec databases that it creates). Anyway, it looks like it replicates the A table just fine, and the slaveb and slavec databases replicate just fine, but the SyncID was incremented by the SlaveA replication, and therefore b and c never get updated. I don't know enough about how the RServ code works right now to fix this right away. Any ideas? Or should I just figure it out for myself? (I know everyone is busy getting ready for the feature freeze) -- Michael A Nachbaur [EMAIL PROTECTED] replicate-testcase.sh Description: application/shellscript ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] pg_dump, schemas and 7.4/7.3
I'd really like to be able to dump a single schema from 7.3 for a current project. Now I can write a script to run \dt and then pg_dump -t each table, but that's not going to help me with sequences etc. Of course, in 7.4 pg_dump will do exactly what I want, which seems to give me two options: 1. Use 7.4 pg_dump to dump my 7.3 schema 2. Back-port pg_dump from 7.4 to 7.3 The questions are: will (1) work, or is (2) a viable option for someone who hasn't coded C for 10+years? TIA -- Richard Huxton ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Updating psql for features of new FE/BE protocol
Bruce Momjian [EMAIL PROTECTED] writes: I think 'is_superuser' is more appropriate. Okay, fine. I forgot one other thing that is available from the recent libpq additions and needs to be exposed by psql: error message verbosity setting. What's there now is described in http://candle.pha.pa.us/main/writings/pgsql/sgml/libpq-control.html to wit, terse, default, and verbose options. We have the choice of exposing this as a backslash command or as a special variable in psql --- any preferences? Also, I would like to provide the same set of options w.r.t. messages logged in the server log. Here there is an additional frammish that could be imagined, ie, more detail for more-serious errors. Any opinions about what it should look like? 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] RServ patch to support multiple slaves (sorta)
On Wed, Jun 25, 2003 at 02:47:52PM -0700, Michael A Nachbaur wrote: Anyway, it looks like it replicates the A table just fine, and the slaveb and slavec databases replicate just fine, but the SyncID was incremented by the SlaveA replication, and therefore b and c never get updated. I don't know enough about how the RServ code works right now to fix this right away. Any ideas? Or should I just figure it out for myself? (I know everyone is busy getting ready for the feature freeze) Hm, I don't quite recall the code right now, but I think you should be trying to put the _rserv_servers_ table to use. In the current version I think it's unused. Then you can store the SyncId on _rserv_sync_ for each slave. You have to modify almost everything to use a SlaveId that references parameters from _rserv_servers_, and pass that as parameter instead of hostnames and such. [... reads some code ...] No, I think this is wrong, but I'm not sure. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Now I have my system running, not a byte was off the shelf; It rarely breaks and when it does I fix the code myself. It's stable, clean and elegant, and lightning fast as well, And it doesn't cost a nickel, so Bill Gates can go to hell. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] RServ patch to support multiple slaves (sorta)
On Wed, 25 Jun 2003, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Patch applied. Thanks. Michael A Nachbaur wrote: Attached is a patch that provides *VERY* limited support for multiple slave servers. I haven't tested it very well, so use at your own risk (and I recommend against using it in production). It sounded to me like that patch was intended for comment, not for application. He said it wasn't all he wanted to do with the code, but that it did work. With so few rserv patches, it seems like something we should get in, but maybe not? Other comments? I am not sure myself. Considering how many ppl have commented in the past how rserv was broken anyway ... ? I'd say it can't hurt anything ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Feature freeze and the great elog changeover
On Wed, 25 Jun 2003, Tom Lane wrote: I had originally planned to spend the next week editing all the elog() calls in the backend to convert them to ereport() format where helpful, add SQLSTATE values, and update wording to match the style guidelines that were agreed to awhile back. However, it looks like the same reasons that were holding me back still apply: any wholesale editing will likely break unapplied patches, plus I'll have to go back through the code when those patches do get applied. With folk scrambling to get last-minute stuff done before feature freeze, these are not good side-effects. What I'd like to do instead is try to get the editing done during the interval between feature freeze and the start of beta (which we've already agreed is July 1 - July 15). I do not feel that this violates the spirit of feature freeze, but does anyone want to object to that plan? Based on the reasons given, it sounds like it would be more harmful not to do it when things are supposed to be frozen ... no objections here ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Updating psql for features of new FE/BE protocol
On Wed, 2003-06-25 at 13:49, Tom Lane wrote: There are a number of things that need to be done in psql before feature freeze. Any comments on the following points? * We need a client-side autocommit-off implementation to substitute for the one removed from the server. I am inclined to create a new psql backslash command: \autocommit on traditional handling of transactions \autocommit off force BEGIN before any user command that's not already in a transaction \autocommit with no arg, show current state An alternative to creating a new command is to define a special variable in psql, whereupon the above three would instead be rendered \set AUTOCOMMIT on \set AUTOCOMMIT off \echo :AUTOCOMMIT The first choice seems less verbose to me, but if anyone wants to make a case for the second, I'm open to it. Note that either of these could be put in ~/.psqlrc if someone wants autocommit off as their default. A case for the latter is that it's very similar to environment variables, a well known system. The main advantage I see -- other than the shell similarities -- is the ability to call set with no arguments and get a listing of all the options. This is currently much shorter than the already overburdened \? screen and would concentrate all psql preference settings in one location. ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Updating psql for features of new FE/BE protocol
[EMAIL PROTECTED] writes: Is it too late to suggest that there be a way to have output displayed on screen AND output to a file? tee perhaps? Tee ALMOST does it. Try doing a \d while tee'ing the output, for example. I don't quite get everything back before it asks for the next input line, sometimes all that is missing is the prompt itself. I haven't set up a 7.4 test system yet, but I've been looking into it in 7.3.3. it gives me something fairly harmless to work on as I learn more C. I think tee may write straight to sysout, so it is probably intermingling with the writes from within psql. I'm not sure why sometimes it is only missing a line or two and other times it is missing several lines. There doesn't appear to be a way to set the popen on the \o command to non-buffer mode or to force a flush on a pipe. (The equivalent of fflush.) I have also noticed that if I have timing on, the timing stats do not get sent to the output file, just to the screen. (That doesn't concern me at this point, it was just a side comment on screen vs file output.) This is irrelevant to what I'm doing, in any case, and it's not an itch I feel personally. Work on it yourself if you want it ... I'm trying to, now I really feel like a rookie! :-) -- Mike Nolan ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Updating psql for features of new FE/BE protocol
Arguile [EMAIL PROTECTED] writes: On Wed, 2003-06-25 at 13:49, Tom Lane wrote: The first choice seems less verbose to me, but if anyone wants to make a case for the second, I'm open to it. Note that either of these could be put in ~/.psqlrc if someone wants autocommit off as their default. A case for the latter is that it's very similar to environment variables, a well known system. The main advantage I see -- other than the shell similarities -- is the ability to call set with no arguments and get a listing of all the options. This is currently much shorter than the already overburdened \? screen and would concentrate all psql preference settings in one location. Fair points. I'm sold on \set AUTOCOMMIT unless someone else wants to try to change my mind again ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Updating psql for features of new FE/BE protocol
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I think 'is_superuser' is more appropriate. Okay, fine. I forgot one other thing that is available from the recent libpq additions and needs to be exposed by psql: error message verbosity setting. What's there now is described in http://candle.pha.pa.us/main/writings/pgsql/sgml/libpq-control.html to wit, terse, default, and verbose options. We have the choice of exposing this as a backslash command or as a special variable in psql --- any preferences? My preference for such things is to use variables. It seems to me that backslash commands should be reserved for actual actions, e.g. show me the list of tables or import data from stdin, etc. It seems to me that variables are a natural way of representing the state of psql, and that changing that state should be accomplished through the standard mechanisms, i.e. \set. Also, I would like to provide the same set of options w.r.t. messages logged in the server log. Here there is an additional frammish that could be imagined, ie, more detail for more-serious errors. Any opinions about what it should look like? Not sure exactly what you're asking for here. If you're asking what additional detail should be included for more serious errors, I'd say it should be things like the actual text of the query being executed and perhaps the file and line number of the code that threw the error. A stack trace could be useful in the most extreme cases (and, obviously, only when verbosity is maximized), too, but that may be too much to ask for. :-) -- Kevin Brown [EMAIL PROTECTED] ---(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] Updating psql for features of new FE/BE protocol
[EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: Is it too late to suggest that there be a way to have output displayed on screen AND output to a file? tee perhaps? Tee ALMOST does it. Try doing a \d while tee'ing the output, for example. Try using script (start it from the shell before invoking psql). It sounds like it'll do much of what you're after. Screen also has a logging option which may work just as well, if not better, than script, and has the additional advantage that the session will continue (and can be reattached to) even if your terminal window dies for whatever reason. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] RServ patch to support multiple slaves (sorta)
That was my feeling, but the author wasn't sure about the patch either, hence it was backed out. --- The Hermit Hacker wrote: On Wed, 25 Jun 2003, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Patch applied. Thanks. Michael A Nachbaur wrote: Attached is a patch that provides *VERY* limited support for multiple slave servers. I haven't tested it very well, so use at your own risk (and I recommend against using it in production). It sounded to me like that patch was intended for comment, not for application. He said it wasn't all he wanted to do with the code, but that it did work. With so few rserv patches, it seems like something we should get in, but maybe not? Other comments? I am not sure myself. Considering how many ppl have commented in the past how rserv was broken anyway ... ? I'd say it can't hurt anything ... -- 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] Updating psql for features of new FE/BE protocol
Kevin Brown [EMAIL PROTECTED] writes: Tom Lane wrote: Also, I would like to provide the same set of options w.r.t. messages logged in the server log. Here there is an additional frammish that could be imagined, ie, more detail for more-serious errors. Any opinions about what it should look like? Not sure exactly what you're asking for here. If you're asking what additional detail should be included for more serious errors, No, I was asking whether anyone thought such behavior should be user-controllable, and if so exactly how the controlling GUC variables should be defined. One way I could imagine doing it is to split log_min_messages into three variables, along the lines of minimum message level to produce a TERSE report, minimum message level to produce a DEFAULT report, and minimum message level to produce a VERBOSE report. This seems a bit inelegant though. Better ideas anyone? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
On Wed, 25 Jun 2003, Shridhar Daithankar wrote: On 25 Jun 2003 at 14:50, Andreas Pflug wrote: Jan Wieck wrote: Change that into * Remove bugs from source code and get a patent on it. Should be a nobrainer (as in those guy's have no brains) considering that NetFlix even got a patent on DVD subscription rentals: http://slashdot.org/article.pl?sid=03/06/24/1458223mode=flattid=155tid=99 I'm applying for a patent on breathing now. The trick I found is reversing the direction of airflow in a regular way. The algorithm seems apparently simple, but it really makes the deal: Step 1. If your lungs are empty, let air flow into them through some air intake. This airflow might be ducted by some bronchial or additional tubing. Step 2 (optional) As soon as there's enough air in the lungs, you may decide to hold it there for a while. Some time limits might apply, please consult some specialist for details. Step 3 Press the air out of the lungs, using some muscles or externally applied force on the chest. The air will eventually escape through some body opening. Another patent I'll be applying for covers the use of nostrils for this purpose. Step 4 Restart the cycle at step 1. Regards and don't dare to try this without royalty fees! Oops... I challenge it for prior art..:-) Why, are you older then he is? I think that is about the only way that 'prior art' would apply here, no? :) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Two weeks to feature freeze
On Wed, 25 Jun 2003, Kevin Brown wrote: So...would it make sense to create a gborg project to which people who have written their own test suites can contribute whatever code and data they feel comfortable releasing? As a gborg project, it would be separate from the main PG distribution and would thus have no impact on the build process or anything like that. But at the same time, if there are any ideas on testing that people have had, they could be shared with others through that mechanism. And any tests which prove to be particularly useful could make their way into the PG distribution if people here wish. Of course, like anything else this could be a bad (or perhaps redundant) idea. :-) It doesn't sound like a bad idea ... but, it pretty much comes down to the original thread: are you willing to step up and maintain such a project? ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] row description for domain in 7.4
I created a domain with text as the data_type. When I get the row description message from the backend for a column using this domain, the type OID provided is for text (25) rather than the OID of the domain I created. I could have sworn I tested this in 7.3.x and the OID was for my domain. 7.4 bug or something I need to work out on my own? Thanks, John DeSoi, Ph.D. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] RServ patch to support multiple slaves (sorta)
On Wed, Jun 25, 2003 at 08:33:04PM -0300, The Hermit Hacker wrote: On Wed, 25 Jun 2003, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Patch applied. Thanks. Michael A Nachbaur wrote: Attached is a patch that provides *VERY* limited support for multiple slave servers. I haven't tested it very well, so use at your own risk (and I recommend against using it in production). It sounded to me like that patch was intended for comment, not for application. He said it wasn't all he wanted to do with the code, but that it did work. With so few rserv patches, it seems like something we should get in, but maybe not? Other comments? I am not sure myself. Considering how many ppl have commented in the past how rserv was broken anyway ... ? I'd say it can't hurt anything ... Are you saying that it doesn't matter that it is made more broken? Sorry if I disagree... we should be trying to fix it, not the other way around. If it's so broken, why hasn't it received any improvement? Is there some problem with the underlying design? I suppose the erServer code is at least vaguely based on this, right? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Nadie esta tan esclavizado como el que se cree libre no siendolo (Goethe) ---(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] RServ patch to support multiple slaves (sorta)
On Wed, 25 Jun 2003, Alvaro Herrera wrote: Are you saying that it doesn't matter that it is made more broken? Sorry if I disagree... we should be trying to fix it, not the other way around. If it's so broken, why hasn't it received any improvement? Is there some problem with the underlying design? I suppose the erServer code is at least vaguely based on this, right? eRServer is to rserv, at this stage, like night is to day ... eRServer is a single master, multislave replication re-written completely in java to make use of the threaded/parallel nature of java to eliminate the deadlocks, and backlogs, that single-threaded presents ... In fact, the *current* eRServer (which we're currently working on the documentation for, and will be shipping out soon) now does multi-database to multi-slave without having to start up several erserver processes, where before you had to do one server per database ... ---(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] Two weeks to feature freeze
Doesn't matter, this entire approach has a fundamental flaw. If the lungs are empty ... that means that the guy has an open thorax, the lungs are collapsed, and you'll probably have problems catching his attention to make your claim. Jan The Hermit Hacker wrote: On Wed, 25 Jun 2003, Shridhar Daithankar wrote: On 25 Jun 2003 at 14:50, Andreas Pflug wrote: Jan Wieck wrote: Change that into * Remove bugs from source code and get a patent on it. Should be a nobrainer (as in those guy's have no brains) considering that NetFlix even got a patent on DVD subscription rentals: http://slashdot.org/article.pl?sid=03/06/24/1458223mode=flattid=155tid=99 I'm applying for a patent on breathing now. The trick I found is reversing the direction of airflow in a regular way. The algorithm seems apparently simple, but it really makes the deal: Step 1. If your lungs are empty, let air flow into them through some air intake. This airflow might be ducted by some bronchial or additional tubing. Step 2 (optional) As soon as there's enough air in the lungs, you may decide to hold it there for a while. Some time limits might apply, please consult some specialist for details. Step 3 Press the air out of the lungs, using some muscles or externally applied force on the chest. The air will eventually escape through some body opening. Another patent I'll be applying for covers the use of nostrils for this purpose. Step 4 Restart the cycle at step 1. Regards and don't dare to try this without royalty fees! Oops... I challenge it for prior art..:-) Why, are you older then he is? I think that is about the only way that 'prior art' would apply here, no? :) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] row description for domain in 7.4
John DeSoi [EMAIL PROTECTED] writes: I created a domain with text as the data_type. When I get the row description message from the backend for a column using this domain, the type OID provided is for text (25) rather than the OID of the domain I created. I could have sworn I tested this in 7.3.x and the OID was for my domain. 7.4 bug or something I need to work out on my own? No, 7.4 intentional change. If you want to argue that this was a bad idea, it's not too late ... but see the archived discussions about it. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Updating psql for features of new FE/BE protocol
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: One way I could imagine doing it is to split log_min_messages into three variables, along the lines of minimum message level to produce a TERSE report, minimum message level to produce a DEFAULT report, and minimum message level to produce a VERBOSE report. This seems a bit inelegant though. Better ideas anyone? I doubt someone would want to control terse/default/verbose at various levels --- I assume they would just want all their messages to be terse/default/ or verbose. shrug That would certainly be the least work to implement. I was fishing to see if anyone felt that more is needed. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Updating psql for features of new FE/BE protocol
--On Wednesday, June 25, 2003 22:58:39 -0400 Tom Lane [EMAIL PROTECTED] wrote: Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: One way I could imagine doing it is to split log_min_messages into three variables, along the lines of minimum message level to produce a TERSE report, minimum message level to produce a DEFAULT report, and minimum message level to produce a VERBOSE report. This seems a bit inelegant though. Better ideas anyone? I doubt someone would want to control terse/default/verbose at various levels --- I assume they would just want all their messages to be terse/default/ or verbose. shrug That would certainly be the least work to implement. I was fishing to see if anyone felt that more is needed. hooks for the next release after we all get some experience with this? -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] recursive queries
What's the chances of getting recursive queries in for 7.4? Chris ---(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] recursive queries
Christopher Kings-Lynne [EMAIL PROTECTED] writes: What's the chances of getting recursive queries in for 7.4? If you mean SQL99 WITH clauses, approximately zero ... unless you had an implementation you were planning to whip out of your hip pocket along about now. Andrew Overholt of Red Hat has been working on this, but is certainly not going to make the Tuesday feature-freeze deadline. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] recursive queries
If you mean SQL99 WITH clauses, approximately zero ... unless you had an implementation you were planning to whip out of your hip pocket along about now. Andrew Overholt of Red Hat has been working on this, but is certainly not going to make the Tuesday feature-freeze deadline. I was just wondering who was working on it and what the progress was...? It seemed to me that it must have been hacked on for quite a long time now? Also, are we getting DB2 or Oracle syntax? Chris ---(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] recursive queries
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Andrew Overholt of Red Hat has been working on this, but is certainly not going to make the Tuesday feature-freeze deadline. I was just wondering who was working on it and what the progress was...? It seemed to me that it must have been hacked on for quite a long time now? Andrew's had the usual quota of corporate demands on his time :-(. Perhaps he'll weigh in here for himself, but I had thought right along that getting it done for 7.4 was chancy. Also, are we getting DB2 or Oracle syntax? SQL99-spec is the intention. I believe this is much closer to DB2 than to Oracle. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Many Pl/PgSQL parameters - AllocSetAlloc(128)?
I said:
It might work to get rid of the wild card case (line 1115), which'd
reduce the number of outputs to product(nsupers+1). I doubt we really
want any wild cards in there anymore.
I've fixed the problem along the above lines. The patch against 7.3
branch is attached in case Reuven would like to apply it locally.
regards, tom lane
*** src/backend/parser/parse_func.c.origWed Apr 23 14:20:10 2003
--- src/backend/parser/parse_func.c Wed Jun 25 15:32:52 2003
***
*** 904,926
*argtype_inherit() -- Construct an argtype vector reflecting the
* inheritance properties of the
supplied argv.
*
! *This function is used to disambiguate among functions with the
! *same name but different signatures. It takes an array of input
! *type ids. For each type id in the array that's a complex type
! *(a class), it walks up the inheritance tree, finding all
! *superclasses of that type. A vector of new Oid type arrays
! *is returned to the caller, reflecting the structure of the
! *inheritance tree above the supplied arguments.
*
*The order of this vector is as follows: all superclasses of the
*rightmost complex class are explored first. The exploration
*continues from right to left. This policy means that we favor
*keeping the leftmost argument type as low in the inheritance tree
*as possible. This is intentional; it is exactly what we need to
! *do for method dispatch. The last type array we return is all
! *zeroes. This will match any functions for which return types are
! *not defined. There are lots of these (mostly builtins) in the
! *catalogs.
*/
static Oid **
argtype_inherit(int nargs, Oid *argtypes)
--- 904,932
*argtype_inherit() -- Construct an argtype vector reflecting the
* inheritance properties of the
supplied argv.
*
! *This function is used to handle resolution of function calls when
! *there is no match to the given argument types, but there might be
! *matches based on considering complex types as members of their
! *superclass types (parent classes).
! *
! *It takes an array of input type ids. For each type id in the array
! *that's a complex type (a class), it walks up the inheritance tree,
! *finding all superclasses of that type. A vector of new Oid type
! *arrays is returned to the caller, listing possible alternative
! *interpretations of the input typeids as members of their superclasses
! *rather than the actually given argument types. The vector is
! *terminated by a NULL pointer.
*
*The order of this vector is as follows: all superclasses of the
*rightmost complex class are explored first. The exploration
*continues from right to left. This policy means that we favor
*keeping the leftmost argument type as low in the inheritance tree
*as possible. This is intentional; it is exactly what we need to
! *do for method dispatch.
! *
! *The vector does not include the case where no complex classes have
! *been promoted, since that was already tried before this routine
! *got called.
*/
static Oid **
argtype_inherit(int nargs, Oid *argtypes)
***
*** 929,950
int i;
InhPathsarginh[FUNC_MAX_ARGS];
! for (i = 0; i FUNC_MAX_ARGS; i++)
{
! if (i nargs)
! {
! arginh[i].self = argtypes[i];
! if ((relid = typeidTypeRelid(argtypes[i])) != InvalidOid)
! arginh[i].nsupers = find_inheritors(relid,
(arginh[i].supervec));
! else
! {
! arginh[i].nsupers = 0;
! arginh[i].supervec = (Oid *) NULL;
! }
! }
else
{
- arginh[i].self = InvalidOid;
arginh[i].nsupers = 0;
arginh[i].supervec = (Oid *) NULL;
}
--- 935,947
int i;
InhPathsarginh[FUNC_MAX_ARGS];
! for (i = 0; i nargs; i++)
{
! arginh[i].self = argtypes[i];
! if ((relid = typeidTypeRelid(argtypes[i])) != InvalidOid)
! arginh[i].nsupers = find_inheritors(relid,
(arginh[i].supervec));
else
{
