[HACKERS] In theory ... news2mail gatewaying test ...
this should get to the list without any problems ... ---(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] 7.4 beta binaries
On 6 Aug 2003 at 9:51, Peter Eisentraut wrote: Shridhar Daithankar writes: Can anybody tell me what flags etc. are to be used. I have a slackware 9.0 installation with most of the developer tools I believe. I can give it a shot. When you configure, enable everything: --enable-nls --enable-thread-safety --with-tcl --with-perl --with-python --with-java --with-krb5 --with-pam --with-openssl Well thanks for all the hints. That was a real nice HOWTO. I will see if I can build that. I am worrid about java part of it. No java on my machine. But will work that out. Use --prefix=/usr. That should get all the paths right. (There may be room for refinement, but not FHS lawyer can argue against what --prefix=/usr gives you.) Add optimizing CFLAGS according to local custom. I think O2 is enough. If the Slackware package system does not strip binaries automatically, use make install-strip instead of make install. It does. Anyway I will be using checkinstall. It will give a single postgresql package. I am not going to make effort of splitting it all along. Personally I find it useful to have everything installed. Call make install-all-headers. Make sure ldconfig is called somewhere. Use /var/lib/postgresql/data as the data dir. Then you need to figure out how to start the server at boot time. Use contrib/start-scripts/linux as a start. OK. Will check that.. And finally, if you find something that local custom dictates but is not easily supported by the standard distribution, let us know. Will keep it updated.. Bye Shridhar -- O'Toole's commentary on Murphy's Law: Murphy was an optimist. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.4 Beta1: variable not found in subplan target lists
Robert Creager [EMAIL PROTECTED] writes: Aug 6 16:24:55 thunder postgres[7835]: [11-1] ERROR: variable not found in subplan target lists I believe I've fixed this as of cvs tip. Thanks for the test case. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] LOCK.tag(figuring out granularity of lock)
following is taken from postgresql-7.3.2/src/backend/storage/lmgr/readme: If we are setting a table level lock both the blockId and tupleId (in an item pointer this is called the position) are set to invalid, if it is a page level lock the blockId is valid, while the tupleId is still invalid. Finally if this is a tuple level lock (we currently never do this) then both the blockId and tupleId are set to valid specifications. how do we check whether blockId and tupleId of LOCK.tag are valid or invalid? is blockId same as tag.objId.blkno? what field in LOCK.tag is tupleId? thanks jenny _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Problem building contrib/array in current CVS
On Thu, Aug 07, 2003 at 13:16:29 -0700, Joe Conway [EMAIL PROTECTED] wrote: Bruno Wolff III wrote: array_iterator.c:30: utils/fmgroids.h: No such file or directory make: *** [array_iterator.o] Error 1 I must have caught something in the middle of an update. I grabbed a fresh copy a little while ago and now it builds properly. I believe utils/fmgroids.h is a derived file. Were you building contrib without first building Postgres? I wasn't intending to. I might have made a mistake, but I am pretty sure that the top level make started and that when I came back to do the make in contrib it looked like the first make had finished normally. Maybe I did something wrong and didn't notice it. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] threads/UnixWare
Bruce Momjian writes: Actually, your getpwuid_r is the old, pre-POSIX format. No, his is the right POSIX/SUS variant. -- Peter Eisentraut [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] postmaster(s) have high load average
After a long battle with technology,
Merlin Moncure [EMAIL PROTECTED], an earthling, wrote:
INAL, but I would read carefully over the Oracle license agreement
and redistribution allowances before doing this, especially if the
database is installed in a commercial environment. With all the
legal activity around open source lately, it seems dangerous
(probably harmless in a test/development environment though).
This begs the question of whether the PL/SQL code in question was
provided by Oracle Corporation or not; that's not clear.
If the person wanting to redeploy it is actually the author of the
code, then Oracle shouldn't have anything to say about it, any more
than Microsoft would have anything to say about code someone wrote in
Visual BASIC, or that SAP AG would about code I wrote in ABAP/4, or
such.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('aa454','freenet.carleton.ca').
http://cbbrowne.com/info/wp.html
I think that helps the users too much. -- CSTACY
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] TODO items
Bruce Momjian [EMAIL PROTECTED] writes: I am marking the completed TODO items. Are these done? * Have standalone backend read postgresql.conf [looks] Nope. No ProcessConfigFile() call in postgres.c. * Prevent whole-row references from leaking memory, e.g. SELECT COUNT(tab.*) Nope. * Use index to restrict rows returned by multi-key index when used with non-consecutive keys or OR clauses, so fewer heap accesses Not sure what this means. * Prevent index uniqueness checks when UPDATE does not modify the column Not done. * Return proper effected tuple count from complex commands [return] I looked at that TODO.detail file, and it all seems to be ancient history. Didn't we resolve those issues to peoples' satisfaction in 7.3? o Allow SHOW of non-modifiable variables, like pg_controldata I put in read-only variables for the things that seemed most interesting (LC_COLLATE for example), but the coverage isn't complete. o Allow array declarations and other data types in PL/PgSQL DECLARE AFAIK this is pretty much fixed. o Add PL/PgSQL PROCEDURES that can return multiple values Not done (unless this is referring to RETURN NEXT, but I think it's talking about multiple output parameters). o Add table function support to pltcl, plperl, plpython Not done. o Allow PL/PgSQL to support array element assignment Done. * Make blind writes go through the file descriptor cache Not done. * Improve Subplan list handling Dunno what this is referring to. * Precompile SQL functions to avoid overhead (Neil) Not done. * Add optional CRC checksum to heap and index pages Not done. o Add optional textual message to NOTIFY Not done, but there is room in the FE/BE protocol now for something like this. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Moved simple_prompt()/sprompt.c
Bruce Momjian [EMAIL PROTECTED] writes: Yes, thread.c, path.c, and sprompt.c should be in utils, but how do I do that? Utils seems to be a place things are pulled from, rather than a library that goes with every link. Is it worth creating another library that acts just like /port but is called utils, or should we just rename the directory to portutils? path.c is arguably okay material for /port, since it is dealing with platform-to-platform variations. sprompt.c is only going to be used by stuff under src/bin. I wonder if we should create a src/bin/utils directory. Not sure about thread.c --- perhaps we could just dump it into libpq. (libpq requires it anyway, no? So why not export it from there and let the apps atop libpq use the same instance.) I am looking to move fmtId() over to port too so psql can use it. It is already used by pg_dump, and /scripts. That's definitely not port/ material. A src/bin/utils/ directory would make sense for it though. 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] TODO items
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I am marking the completed TODO items. Are these done? * Have standalone backend read postgresql.conf [looks] Nope. No ProcessConfigFile() call in postgres.c. OK. * Prevent whole-row references from leaking memory, e.g. SELECT COUNT(tab.*) Nope. OK, I wasn't sure because you had done per-tuple memory contexts. * Use index to restrict rows returned by multi-key index when used with non-consecutive keys or OR clauses, so fewer heap accesses Not sure what this means. This is a Vadim idea. The idea was that if you had a multi-key index on col1,col2,col3, and you wanted to do a lookup on col1,col3, you could still use the index, and just run through all the matching col1 values looking for a matching col3 in the index, rather than going to the heap and looking for a col3 match? Is this item worth keeping? * Prevent index uniqueness checks when UPDATE does not modify the column Not done. OK. * Return proper effected tuple count from complex commands [return] I looked at that TODO.detail file, and it all seems to be ancient history. Didn't we resolve those issues to peoples' satisfaction in 7.3? I think so. I think MOVE was our last one. o Allow SHOW of non-modifiable variables, like pg_controldata I put in read-only variables for the things that seemed most interesting (LC_COLLATE for example), but the coverage isn't complete. I modified the item to say some and marked it as done: o -Allow SHOW of some non-modifiable variables, like pg_controldata Anyone want it kept? o Allow array declarations and other data types in PL/PgSQL DECLARE AFAIK this is pretty much fixed. OK. Already reported by Joe. o Add PL/PgSQL PROCEDURES that can return multiple values Not done (unless this is referring to RETURN NEXT, but I think it's talking about multiple output parameters). I am asking Josh for a new item with clearer wording. Once we finish some items, the wording often needs adjusting. o Add table function support to pltcl, plperl, plpython Not done. OK. o Allow PL/PgSQL to support array element assignment Done. OK. * Make blind writes go through the file descriptor cache Not done. OK. * Improve Subplan list handling Dunno what this is referring to. I assume it is related to the subquery stuff you did. I have marked it as done. * Precompile SQL functions to avoid overhead (Neil) Not done. OK. * Add optional CRC checksum to heap and index pages Not done. OK. o Add optional textual message to NOTIFY Not done, but there is room in the FE/BE protocol now for something like this. OK. Thanks. TODO updated. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
[HACKERS] Just ignore ... just a test
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: [EMAIL PROTECTED] secondary: [EMAIL PROTECTED]|postgresql}.org ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] PostgreSQL 7.4 Beta 1 + SSL + Cygwin
Hello: I want to know if postgresql 7.4 beta 1 can be configured under Cygwin with SSL support ?? If the answer is positive how can i do it ?? or where can i found documentation about this ( under linux or cygwin :) ) ?? I have found this on PostgreSQL docs :) i have it configured yet. -- Best regards Carlos Guzmán Álvarez Vigo-Spain ---(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] threads/UnixWare
--On Friday, August 08, 2003 11:53:34 +0100 Lee Kindness [EMAIL PROTECTED] wrote: I've not been keeping up with the thread re who has what version of getpwuid_r... But just to clarify things the right version is: int getpwuid_r(uid_t uid, struct passwd *pwd, char *buffer, size_t bufsize, struct passwd **result); documented at: http://www.opengroup.org/onlinepubs/007904975/functions/getpwuid.html My email to Bruce which he tacked onto his reply is a good summary of the current problems with the thread stuff. Ok. Lee: Did you see the patch I posted? Can you help on the configure test(s) needed to set HAVE_POSIX_GETPWUID_R? I **THINK** I did the patch right to handle it if it's set. I forced it for UnixWare and it seems to work. LER L. Larry Rosenman writes: --On Friday, August 08, 2003 02:10:25 -0400 Bruce Momjian [EMAIL PROTECTED] wrote: Actually, your getpwuid_r is the old, pre-POSIX format. The attached email has the configure tests. I was hoping we wouldn't need them, butit seems we may. Err, SCO claims SUSv2, the Single Unix Specification Version 2. V3 **JUST** came out. I'll look at Lee's stuff. -- 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 -- 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 8: explain analyze is your friend
Re: [HACKERS] v7.4 Beta 1 fails regression on Digital Unix/Tru64 4.0
Alessio Bragadini [EMAIL PROTECTED] writes: The first beta fails two regression tests on alphaev67-dec-osf4.0g, compiled by cc -std -std i.e. Compaq/HP Digital Unix/Tru64/name-of-the-day They are join (FAILED) and random (failed ignored). Attached is the regression diff. AFAICT, the diffs simply indicate that psql isn't echoing the input commands --- ie, it's not honoring the \set ECHO all command that is fed to it by the regression script. Which is odd in itself, and especially odd that it happens only in two out of 90-odd tests. I think you have a psql bug to chase. During configuration a warning stated that our version of Bison was outdated, can it be related? No. psql doesn't depend on bison. A build from a tarball doesn't use your local bison anyway (unless you build contrib). regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] consistency check on SPI tuple count failed
Stephan Szabo [EMAIL PROTECTED] writes: On Fri, 8 Aug 2003, Tom Lane wrote: I have also just traced through _SPI_cursor_operation() in spi.c, watched PortalRunFetch return 2, and then watched _SPI_checktuples read zero from _SPI_current-processed. How the heck could that happen? Compiler bug, or am I just crazy? Not sure, but I got the same thing. When I changed it to put the result in a temporary int variable and then put it in it started working for me (returning 0), reverting to the original made it fail again. I'm going to try -O0 and see what happens there. Oooo ... lightbulb SPI_stack can move around as functions are entered/exited. /lightbulb Wonder why we've not seen that kind of failure happen before? Someone (doubtless me) must have changed the coding of this routine since 7.3. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] TODO items
Josh Berkus wrote: Actually, now that I look at it again, it is referring to procedures, not functions. Maybe just make it: o Add capability to create and call PROCEDURES OK. I need to put a full proposal behind this once 7.4 is in the can. However, this is largely academic until we get someone who really wants to take ownership of PL/pgSQL and has the coding skills (I have the former but not the latter). This isn't isolated to just PL/pgSQL, just like the ability to create and call functions isn't. Support for PROCEDUREs in the backend is a prerequisite to being able to use PL/pgSQL to create procedures. It is necessary but not sufficient. Similarly, if we want to support IN/OUT or named parameters, it isn't a PL/pgSQL issue per se, it is a general one. Joe ---(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] LOCK.tag(figuring out granularity of lock)
On Fri, Aug 08, 2003 at 12:15:07PM -0700, Jenny - wrote: following is taken from postgresql-7.3.2/src/backend/storage/lmgr/readme: [...] Is this on a crontab or something? It has gotten very annoying lately. -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Right now the sectors on the hard disk run clockwise, but I heard a rumor that you can squeeze 0.2% more throughput by running them counterclockwise. It's worth the effort. Recommended. (Gerry Pourwelle) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] WITH HOLD and pooled connections
Bruce Momjian [EMAIL PROTECTED] writes: Tom Lane wrote: Yeah. I'm leaning towards the idea that a protocol addition is what to do. I am confused why a protocol change would be desired. I was thinking that you might want it at a lower level than having to issue a SQL command to get at the data. A lot of what we changed in the 7.4 protocol revision involved eliminating the need to use SQL commands to get at information that a client library needs. But see my later note questioning just how useful these features would really be. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] 7.4beta compile warning
Gaetano Mendola [EMAIL PROTECTED] writes: gcc -O2 -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o execScan.o execScan.c execScan.c: In function `tlist_matches_tupdesc': execScan.c:199: warning: unused variable `att_tup' Looks like you're the first person to build 7.4 without --enable-cassert ... or at least the first one who looked for warning messages. Fixed. In file included from preproc.y:6278: pgc.c: In function `yylex': pgc.c:1386: warning: label `find_rule' defined but not used /usr/include/ctype.h: At top level: pgc.c:3367: warning: `yy_flex_realloc' defined but not used These are flex's fault. We could get around them but the work needed is unreasonable. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.4 beta binaries
Shridhar Daithankar writes: Can anybody tell me what flags etc. are to be used. I have a slackware 9.0 installation with most of the developer tools I believe. I can give it a shot. When you configure, enable everything: --enable-nls --enable-thread-safety --with-tcl --with-perl --with-python --with-java --with-krb5 --with-pam --with-openssl Use --prefix=/usr. That should get all the paths right. (There may be room for refinement, but not FHS lawyer can argue against what --prefix=/usr gives you.) Add optimizing CFLAGS according to local custom. When you install, run something like make install DESTDIR=/tmp/foo This will give you a fake-root installation under /tmp/foo that you can archive without having to affect your running system. If the Slackware package system does not strip binaries automatically, use make install-strip instead of make install. Call make install-all-headers. Make sure ldconfig is called somewhere. Use /var/lib/postgresql/data as the data dir. Then you need to figure out how to start the server at boot time. Use contrib/start-scripts/linux as a start. And finally, if you find something that local custom dictates but is not easily supported by the standard distribution, let us know. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] WITH HOLD and pooled connections
Andrew Dunstan [EMAIL PROTECTED] writes: Tom Lane wrote: Prepared statements would be just as much of a problem. I think the correct answer is simply don't use those features in a pooled environment. Ouch. Double ouch in fact. I'm using prepared statements extensively in my current (pooled conn) app. All pure selects. Can this be narrowed down a bit? Is it a problem on all query types? The point is just that there's no infrastructure to manage prepared statements, eg for a thread to discover whether someone has already prepped a particular statement on the current connection. Evidently you have set things up so that you don't need to do that. Panic not. regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Release changes
Bruce Momjian [EMAIL PROTECTED] writes: Here are the changes for 7.4. I am looking for any improvements. This will be adjusted as we move through beta. Some notes on specific items: Update /tmp socket files regularly to avoid their removal (Tom) More specifically, update the file mod times. New client/server protocol: faster, no username length limit, allow clean exit allow clean exit from failed COPY is what's meant I think. Not sure I'd claim faster, either. There are a lot of other features you could mention instead, such as allowing separation between SQL commands and data values. Improve reverse index scan performance (Tom) I have no idea what this entry is talking about --- I could not find anything in the CVS log that seemed to match. postgres --help-config now dumps server config variables (Tom) This was not my work, I just applied it. Please credit Aizaz Ahmed. Prevent assign_session_authorization() from being confused by all-numeric user names (Tom) This one is already in 7.3 patch releases, should not appear here. Allow ORDER BY in FROM subqueries to be honored by outer queries (Tom) honored by? Better wording: Avoid redundant sort when order of a subquery result matches outer query's needs Also, this belongs under Performance, I think. Print key name in foreign-key violation messages (Dmitry Tkach) Print key name and value ... Allow subquery aggregates to reference upper query columns (?) (Tom) Poorly phrased. How about: Execute aggregates that reference outer-query values correctly per SQL spec Allow dollar signs in identifiers, except as first character (Tom) Why is this not together with the mention that dollar signs are *not* allowed anymore in operator names? It might also be worth pointing out that x=$1 works without spaces now. Allow zero-column tables (Tom) We allowed this already in 7.3, though I may have fixed a few more bugs. Add pg_trigger.tgenabled to disable triggers? (Neil) tgenabled was there already; the patch just caused it to be checked in more places. Have parser honor foreign-key constraints if created via ALTER TABLE ADD COLUMN? (Tom) This was fixed in a 7.3.* release, should not be listed here. Improve DOMAIN automatic type casting (Tom) I think Rod had something to do with that, too. Object owners can allow grantees to grant privilege to others? Better Implement GRANT OPTION privileges, per SQL spec (Peter) Properly handle SCROLL with cursors, or report an error (Tom) Someone else (Neil I think) did the bulk of the work for scrollable cursors. Allow CLUSTER without tablename clusters all tables (Alvaro Herrera) Better worded Allow ... to cluster all tables Reduce memory used by COPY (Tom) Better Prevent possible memory leaks in COPY. I don't think that patch actually reduced normal memory consumption at all. Syntax errors now reported as 'syntax error' rather than 'parse error' (Tom) Should credit the bison guys ;-) ... that was their change not ours. But really I see no need to list it at all --- there are vastly more wording changes in the error messages than just this one. Have COMMENT ON DATABASE on non-local database generate a warning (Tom) I think that was someone else's work ... Rod maybe? New hostmast() function (Greg Wickham) hostmask() I think you meant? Allow polymorphic SQL functions (Tom, Joe) I think Joe should get the bulk of the credit on this one. Allow array concatenation with '||' and normal array comparisons (Joe) You already mentioned array comparisons, three or four items before. Allow PREPARE/bind of utility commands like FETCH and EXPLAIN (Tom) Doesn't seem like that belongs under data types. Honor only DateStyle setting for date entry without a four-digit year (Greg) Better Allow only DateStyle-specified field order for dates that are not in unambiguous ISO format (-mm-dd) 'now' will no longer work as a default, use now() (change required for prepared statements) (Tom) Maybe say as a column default there. Assume NaN value to be larger than any other value in comparisons (Tom) We did this already in most places. Specify that the change is just to make MIN() and MAX() agree with the rest of the operations. Prevent PL/pgSQL crash when RETURN NEXT is used on a zero-row record (Tom) Zero-column record maybe? I don't know what a zero-row record is. Change PL/pgSQL EXECUTE INTO to CREATE TABLE AS EXECUTE? (Peter) That patch applied to the main parser's EXECUTE command, not plpgsql. So this is in the wrong place as well as being wrong... Allow polymorphic PL/pgSQL functions (Tom, Joe) Improved compiled function caching mechanism in PL/pgSQL with full support for polymorphism (Tom, Joe) Add new $0 parameter in PL/pgSQL representing the function's actual return type (Tom, Joe) Again, Joe gets the bulk of the credit on all three of these (and all the credit for $0, I didn't do anything there) New '\set autocommit off' capability (Tom) It's \set AUTOCOMMIT,
Re: [HACKERS] Release changes
Thinking hard about wording... Add partially implemented FOR EACH STATEMENT statement-level triggers (Neil Conway) which doesn't look nice but expresses what's implemented. Taken from the CREATE TRIGGER FOR EACH STATEMENT documentation, a user would think he could do the same stuff as on lets say MSSQL, in a way known from row-level triggers. The example trigger-example.html seems to be non-statement-level trigger aware. Chapter 37 is quite misleading, for example recursive triggers are mentioned programmer's responsibility to avoid infinite recursionsuggesting there would be a way to know about the affected rows... Actually, I'd consider not to mention statement triggers at all. In the current state, they will provoke some annoyance if people try to use them. We will see them on the mailing lists, seeking for what's currently not available... Regards, Andreas Bruce Momjian wrote: Do you have suggested wording? --- Andreas Pflug wrote: Bruce Momjian wrote: Here are the changes for 7.4. I am looking for any improvements. This will be adjusted as we move through beta. --- Add FOR EACH STATEMENT statement-level triggers (Neil Conway) AFAICS the current implementation still doesn't have a way to access the affected rowset, so it'a pretty much like a SELECT without a WHERE. This restricts the usability of statement-level triggers to very limited cases. IMHO it's not a good idea to announce an incompletely implemented feature. ---(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] Correlation in cost_index()
On Fri, 8 Aug 2003 16:53:48 -0700, Sean Chittenden [EMAIL PROTECTED] wrote: # SHOW effective_cache_size ; effective_cache_size -- 4456 (1 row) Only 35 MB? Are you testing on such a small machine? The stats are attached bzip2 compressed. Nothing was attached. Did you upload it to your web site? I can say with pretty high confidence that the patch to use a geometric mean isn't correct ... the problem with your patch was that it picked an index less often than the current code when there was low correlation. In cost_index.sxc I get lower estimates for *all* proposed new interpolation methods. Either my C code doesn't implement the same calculations as the spreadsheet, or ... I manually applied bits of it [...] ... could this explain the unexpected behaviour? I'm currently downloading your dump. Can you post the query you mentioned above? Servus Manfred ---(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] WITH HOLD and pooled connections
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: TODO item? Yeah. I'm leaning towards the idea that a protocol addition is what to do. I put this under Clients: * Allow clients to query WITH HOLD cursors and prepared statements I am confused why a protocol change would be desired. I though we would just have a function that listed that info to the client. -- 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 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Moved simple_prompt()/sprompt.c
Bruce Momjian writes: If a file is needed by three non-backend directories, /port seems to be the proper place for it. src/port is intended for replacement implementations of standard library functions. If we make it an everything that is used in more than one place directory, we should be very clear about that strategy. Else, src/utils might be a better place. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Correlation in cost_index()
Sean Chittenden [EMAIL PROTECTED] writes: Which suggests to me that line 3964 in ./src/backend/utils/adt/selfuncs.c isn't right for multi-column indexes, esp for indexes that are clustered. I don't know how to address this though... Tom, any hints? Yes, we knew that already. Oliver had suggested simply dropping the division by nKeys, thus pretending that the first-column correlation is close enough. That seems to me to be going too far in the other direction, but clearly dividing by nKeys is far too pessimistic. I'd change this in a moment if someone could point me to a formula with any basis at all ... 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] TODO items
OK, TODO updated. --- Joe Conway wrote: Bruce Momjian wrote: o Add PL/PgSQL PROCEDURES that can return multiple values Do you have TODO to add for this? I removed the original one because, as worded, it was complete. Actually, now that I look at it again, it is referring to procedures, not functions. Maybe just make it: o Add capability to create and call PROCEDURES Joe -- 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
[HACKERS] Proposed macros for error fields
I propose to add the following macros for the fields of an error or notice message for use in libpq applications. The names are modelled after the ones that ODBC uses. (Well, at least they are chosen not to collide in case we want to continue on that track.) S PG_DIAG_SEVERITY C PG_DIAG_SQLSTATE M PG_DIAG_MESSAGE_PRIMARY D PG_DIAG_MESSAGE_DETAIL H PG_DIAG_MESSAGE_HINT P PG_DIAG_STATEMENT_POSITION W PG_DIAG_STACK_TRACE F PG_DIAG_SOURCE_FILE L PG_DIAG_SOURCE_LINE R PG_DIAG_SOURCE_FUNCTION Comments? -- Peter Eisentraut [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] TODO items
Joe Conway [EMAIL PROTECTED] writes: This one I don't understand: o Support construction of array result values in expressions Not sure why you don't understand it, when you did it ;-). It's asking for the ARRAY[] syntax. Bruce, that one should be marked done. I thought Peter did something with this one: * Allow LIKE indexing optimization for non-ASCII locales Yeah, he did. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] When did we get to be so fast?
On Thu, 7 Aug 2003, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I was just testing the threaded ecpg, and ran some performance tests. Without using threads, I am seeing 100,000 inserts of a single word into a simple table take 12 seconds: CREATE TABLE test_thread(message TEXT); giving me 8333 inserts per second. That seems very high. Single transaction, or one transaction per INSERT? This is ecpg, and I didn't have AUTOCOMMIT on, so it was a single transaction. I had forgotten that. Also, I was wrong in my computations. It is 4166 inserts per second, not 8333. Sorry. I am now seeing more reasonable numbers: one INSERT per transaction, fsync true 934 one INSERT per transaction, fsync false 1818 one INSERT per transaction, fsync true 4166 Shouldn't 1 and 3 be about the same though? If both are 'one INSERT per transaction with fsync true', how come such a massive difference in #s? ---(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] TODO: trigger features
Tom Lane wrote: Andreas Pflug [EMAIL PROTECTED] writes: Tom Lane wrote: This can already be done by comparing old and new values, no? No, this is not the case. UPDATE foo SET x=x, y=y is different from UPDATE foo SET y=y if triggers maintaining x are involved. Only for what I would call extremely weird semantics of the triggers. If a trigger preceding yours did the same action (assigned x to itself), would you consider that something you needed to track? If so, how would you find out about it? You couldn't. If you want me to believe that the above is an important requirement, you'd better convince me that it's sane, because I don't think so. I'm talking about a real life problem, and the upper sample was just an essence. Consider this: Table with one column that is maintained by a trigger for this rule: - Only one row in a group of rows may have a foo-value of true, all others must be false. - If foo=true is inserted/updated, other members of that data group must be set to false. - If foo=false, designate one row for foo=true - If not touched, use true if first member of that group, or false This can be maintained by a trigger, but it will possibly trigger itself recursively (but doesn't need a second recursion) Now we have another column: ts timestamp, that should contain the timestamp when the row was inserted/updated the last time by the *user*, not the trigger which is considered to work in the background. On INSERT, a DEFAULT current_timestamp will be the selected option, on UPDATE you would use NEW.TS := current_timestamp. But how to update the row, and retain the old timestamp value? Normally, a user's query wouldn't touch the ts column at all, leaving it to the backend to insert the correct values. But in the maintain foo trigger case, we could use SET ts=ts to signal to the trigger that we explicitely want to set the value. Same applies for the import case, when we want to insert a ts value coming from elsewhere but not from the trigger. This could also be done if there was something like UPDATE ... WITH OPTION NOTRIGGER(trg_update_timestamp) or so. Regards, 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] consistency check on SPI tuple count failed
On Fri, 8 Aug 2003, Tom Lane wrote: Gaetano Mendola [EMAIL PROTECTED] writes: the following code was working properly under Postgres 7.3.X I'm now running my regression test with Postgres 7.4beta1 and I'm having the error in subj. I tried this and got regression=# select bar(); bar - 0 (1 row) regression=# Anyone else see the problem? I got the same thing as Gaetano on my just prior to beta1 system. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
