Re: [HACKERS] new psql \d command
Bruce Momjian wrote: Tom Lane wrote: Christopher Kings-Lynne [EMAIL PROTECTED] writes: It might be a bit risky getting pg_dump to use it though? I definitely don't want pg_dump using the pretty-print stuff ;-). I'm neutral on whether to use it in psql's \d commands. I thought the pretty-printing stuff was designed specifically for psql \d and third-party apps like pgadmin. Yes it was, but it can be meaningful for pg_dump too. The pretty-print stuff will inflate the dump with many spaces which doesn't make any sense with formats not meant to be read by humans, (--format=c), but --format=p output might well be used for user editing. So IMHO an option to enable pretty-dump can be useful. Regards, Andreas ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Release changes
Done. --- Oleg Bartunov wrote: On Tue, 5 Aug 2003, Bruce Momjian wrote: Oleg Bartunov wrote: Bruce, you forgot new contrib/tsearch2 module - full text extension (Oleg,Teodor) Sorry, added: New tsearch2 full-text search module (Oleg) Bruce, I wrote (Oleg,Teodor) Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: [EMAIL PROTECTED], http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html -- 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] Thread-safe configuration option appears to
We don't know the ramifications of doing that flag in the backend code, and we don't know the performance problems of doing it in client libraries. First get your own platforms enabled for the existing thread flag, and we can revisit this when most/all our platforms are supported. We want to avoid confusion of having things work for some platforms and not others with no way to communicate that to the users. --- Lee Kindness wrote: Larry Rosenman writes: What the fr*** harm is it in passing -D_REENTRANT into the libpq build on UnixWare irregardless of the --with-threads* flag? Indeed for every other sane system out there. Folk are messing around with the thread stuff using here-say as knowledge. We want to compile with _REENTRANT, always! Anything needed in ADDITON to _REENTRANT (i.e thread link flags for libecpg) can be discovered by configure and applied to the build. Even for the rest of PostgreSQL, it will work A-OK if we are already sticking to the rules (i.e. including errno.h when using errno). L. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [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 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] WITH HOLD and pooled connections
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Seems we have a problem with pooled connections and WITH HOLD cursors. We have code to reset transaction state and variables via RESET ALL, but how do we remove WITH HOLD cursors when we pass a connection to a new client? 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. regards, tom lane 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? On all versions? What if the statement object (in JDBC) is closed? If it's really a problem I'll have to do some nasty last-minute recoding (again!) :-( (or abandon using pooling, which I would also hate). andrew ---(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] v7.4 Beta 1 fails regression on Digital Unix/Tru64 4.0
I said: 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. I thought of another possibility. The part of pg_regress that is doing this looks like (cat EOF \\set ECHO all EOF cat $inputdir/sql/$name.sql) | \ $PSQL -d $dbname $outputdir/results/$name.out 21 which means that the \set ECHO command is sourced from a separate cat process than the one that emits the test script proper. If, for some reason, that cat failed in those two regression tests, then we'd see the observed symptoms --- and AFAIK the regression script wouldn't complain otherwise. The trouble with this theory is thinking of a plausible reason for those two cats to fail when everything else works. The only thing that comes to mind for me is running into a per-user limit on the number of processes. However, these two tests appear in a sixteen-test parallel set, which is not the widest parallelism in the regression tests (there's a twenty-way test set earlier). So it's a little hard to credit that these would fail when the earlier set passed. You would have to assume that in between the 20-way step and the 16-way step, a whole bunch of other postgres-owned processes were started. So the theory seems shaky to me, but maybe you can think of a variant that is plausible for your environment. Another thing worth asking is whether the failure is repeatable? Try ten or so regression runs and see if they all act the same. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] logging stuff
Mendola Gaetano [EMAIL PROTECTED] writes: Tom Lane [EMAIL PROTECTED] writes: A variant (which'd be okay with me) is to separate these fields with tabs instead of spaces; then the rule for DBAs would be don't allow tabs in db/user names. do you see: ^I that are chars that syslogd hate. Ugh. Okay, scratch that idea ... 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] 7.4beta1 build problem on unixware
Larry Rosenman [EMAIL PROTECTED] writes: Ok, with using OUR src/port/getaddrinfo.c (by #undef'ing HAVE_GETADDRINFO and adding getaddrinfo.o to Makefile.global's LIBOBJS, it works again. We need to devise a configure test for broken/old getaddrinfo()'s. That seems Turing-complete in general :-(. It may well be that the problem is not so much that your getaddrinfo doesn't work, as that we're not interfacing to it correctly. Which of the macros in src/include/getaddrinfo.h are actually being absorbed from the system headers, and which are we using our own values for? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] getting confused parsing ACLITEMS...
Christopher Kings-Lynne [EMAIL PROTECTED] writes: More to the point, this is highly incomplete... you did not teach the adjacent getid routine about this, and there is code in (at least) pg_dump.c that knows the quoting conventions used here. Hang on - those routines can parse the acls just fine? How? How do they handle usernames with equals signs in them (my major prob). How can it work at all? IIRC, the present code assumes that usernames won't contain embedded doublequotes. I did recently fix pg_dump to work in cases that it wouldn't have handled before, including embedded equals. (BTW, my mistake above: the pg_dump code is not in pg_dump.c, but in dumputils.c. Look at copyAclUserName in particular.) 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] 7.4 Beta1 elog problem
On Wed, 06 Aug 2003 15:41:47 -0700 Joe Conway [EMAIL PROTECTED] said something like: Robert Creager wrote: psql:dbTriggers.sql:30: ERROR: could not load library /usr/local/pgsql/triggers/tassiv_triggers.so: /usr/local/pgsql/triggers/tassiv_triggers.so: undefined symbol: elog Am I missing something? I was previously running 7.3.3... elog is defined now as a macro (in utils/elog.h). Did you recompile your trigger function after installing 7.4? Joe Sigh... I did, multiple times, but I didn't pay enough attention. The .o was not rebuilding. The .so was. Thanks for the tip. Cheers, Rob -- 19:38:57 up 5 days, 12:25, 3 users, load average: 2.08, 2.06, 2.01 pgp0.pgp Description: PGP signature
Re: [HACKERS] session level locks
Jenny - [EMAIL PROTECTED] writes: hi, does anyone know what session level locks mean in postgresql..i've heard of table-level locks and row level locks but not session level It's a hack for VACUUM. VACUUM needs to run two transactions to vacuum both a table and its toast table; plus another one if it's going to ANALYZE. Ordinary locks would go away at transaction commit. Session locks are used to ensure the table doesn't disappear till we're done vacuuming. I doubt that session locks as currently designed are good for anything except VACUUM. They *do* go away on error abort --- which is exactly what VACUUM wants, but is unlikely to be useful behavior for anything else. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] build on unixware 713
I passed him mine, and he still sees it. Did either of you use -O without -g? I'll play tonite. LER --On Thursday, August 07, 2003 16:49:41 -0400 Tom Lane [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] writes: UX:acomp: ERROR: fe-protocol3.c, line 1402: internal compiler error: can't deal with op BMOVE I think you need a compiler with fewer internal errors ;-). Is there an update available? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- 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 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] WITH HOLD and pooled connections
Whew. To the best of my knowledge, JDBC at least doesn't provide any API by which one could discover such a thing anyway, (although I guess a given driver could implement some sort of statement cache with a name lookup mechanism). I guess if it were part of the standards JDBC API we'd have heard calls for its support by now. When you think about it its a nice idea. (You are right - all my prepped statements are used and disposed of within a single use of a connection in a single thread.) OK ... back to logging stuff ... andrew Tom Lane wrote: 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] build on unixware 713
The SCO compilers are notoriously buggy for the past 10-15 years. --- Tom Lane wrote: [EMAIL PROTECTED] writes: Larry just given me his own compiler and I still have the errors... [experiments a little...] Hmm. It works okay with -g, but fails with -O. I suggest filing a bug report. I'm not planning to spend any time looking for workarounds for SCO's compiler bugs. 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 -- 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] Correlation in cost_index()
On Thu, 7 Aug 2003 13:44:19 -0700, Sean Chittenden [EMAIL PROTECTED] wrote: The indexCorrelation^2 algorithm was only a quick hack with no theory behind it :-(. I've wanted to find some better method to put in there, but have not had any time to research the problem. Could we quick hack it to a geometric mean instead since a mean seemed to yield better results than indexCorrelation^2? Linear interpolation on (1-indexCorrelation)^2 (algorithm 3 in http://members.aon.at/pivot/pg/16-correlation-732.diff) is almost as good as geometric interpolation (algorithm 4 in the patch, proposal 3 in this thread), and its computation is much cheaper because it does not call exp() and log(). Download http://members.aon.at/pivot/pg/cost_index.sxc and play around with your own numbers to get a feeling. (1-indexCorrelation)^2 suffers from the same lack of theory behind it as indexCorrelation^2. But the results look much more plausible. Well, at least to me ;-) Servus Manfred ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] WITH HOLD and pooled connections
Rod Taylor [EMAIL PROTECTED] writes: On Fri, 2003-08-08 at 16:00, Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Seems we have a problem with pooled connections and WITH HOLD cursors. We have code to reset transaction state and variables via RESET ALL, but how do we remove WITH HOLD cursors when we pass a connection to a new client? 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. Actually, prepared statements in a pooled environment would be very useful if you could ask what the currently prepared names for that connection are. Hm. Good thought. Maybe the same is true of held cursors. It would be a simple addition at either the protocol or SQL level to list the names of existing prepared statements and portals. Probably too late for 7.4 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] WITH HOLD and pooled connections
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: What would be interesting is a CREATE OR REPLACE functionality for prepared cursors, where you could ask for it to be prepared, but if it already existed, it would do nothing, or something like that. I don't think you could call that CREATE OR REPLACE, because (if it's supposed to be efficient) it *wouldn't* replace. In any case I think apps would prefer to avoid the overhead of even issuing such a command. If you approach it that way, you're adding some number of additional SQL commands to each pooled transaction, which seems to defeat the purpose of pre-preparing commands. Of course, it wouldn't be called CREATE OR REPLACE but something like that, or a flag to PREPARE. I assume the prepare overhead is much higher than a single query parse. How would you get the info without issuing a command to get it. You could get it via some protocol request, but that seems pretty hard to manage from libpq up to your interface, and is the extra effort worth avoiding sending a query? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] 7.4 Beta1 elog problem
I grabbed REL7_4_BETA1 from cvs this morning, and am having a problem. A trigger I wrote uses 'elog', which is apparently not defined any more in my build. The documentation doesn't build (my problem), but doc/src/sgml/spi.sgml indicates that elog should be valid. The error I receive when installing the trigger is: psql:dbTriggers.sql:30: ERROR: could not load library /usr/local/pgsql/triggers/tassiv_triggers.so: /usr/local/pgsql/triggers/tassiv_triggers.so: undefined symbol: elog Am I missing something? I was previously running 7.3.3... Thanks, Rob -- 10:22:20 up 5 days, 3:08, 3 users, load average: 2.09, 2.10, 2.04 pgp0.pgp Description: PGP signature
[HACKERS] logging changes - sample output
I ended up doing more or less what Bruce suggested, for 2 reasons - first it is extensible, and second it avoids hardcoding any special separators. The new config variable is set like this: log_line_format = '%U%%%D ' # %U=username %D=databasename %%=% Sample output including session logging when log_connections= true: 2003-08-09 14:33:22 [14219] LOG: database system was shut down at 2003-08-09 14:33:17 EDT 2003-08-09 14:33:22 [14219] LOG: checkpoint record is at 0/27A3470 2003-08-09 14:33:22 [14219] LOG: redo record is at 0/27A3470; undo record is at 0/0; shutdown TRUE 2003-08-09 14:33:22 [14219] LOG: next transaction id: 6235; next oid: 154553 2003-08-09 14:33:22 [14219] LOG: database system is ready 2003-08-09 14:33:35 [14222] LOG: connection received: host=localhost port= 2003-08-09 14:33:35 [14222] andrew%adtest LOG: connection authorized: user=andrew database=adtest 2003-08-09 14:33:53 [14222] andrew%adtest LOG: query: create table foo (x text, y text); 2003-08-09 14:34:07 [14222] andrew%adtest LOG: session ended: duration: 0:00:32.807689 user=andrew database=adtest 2003-08-09 14:34:22 [14217] LOG: received fast shutdown request 2003-08-09 14:34:22 [14225] LOG: shutting down 2003-08-09 14:34:25 [14225] LOG: database system is shut down I'll clean this up (don't think we really need microsec granularity on session logging) and submit the patch this weekend. cheers andrew ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
[HACKERS] simple_heap_update problem
For the last few weeks (still haven't figure out what changed before this started) one of our apps has been generating this error message on the backend one or two times a day. I'm pretty sure it's not an application error since it can be successfully re-run with the same inputs. The application does several queries and I'm not sure which one causes the error. I searched the web and found this error being caused by concurrent ANALYZE commands, but that's not happening here. Aug 7 13:23:30 calchas postgres[27794]: [3] ERROR: simple_heap_update: tuple concurrently updated Aug 7 13:23:30 calchas postgres[27794]: [4] WARNING: AbortTransaction and not in in-progress state Any ideas? I realize this isn't too much information -- what can I do (besides logging queries, which I just started) to get more? --Nate ---(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
On Fri, Aug 08, 2003 at 04:00:22PM -0400, 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. Well, unless you're prepared to manually manage these resources yourself (i.e. DEALLOCATE a prepared query when you're finished with it, CLOSE a holdable cursor). -Neil ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] new psql \d command
On Fri, Aug 08, 2003 at 09:17:05AM +0800, Christopher Kings-Lynne wrote: australia=# \d affiliates_transactions View public.affiliates_transactions [...] View definition: SELECT palm_buyers.affiliate_id, timestamptz(abstime(palm_buyers.datetime)) AS date, 'Palm' AS type, 1 AS type_id, palm_buyers.affiliate_amount AS amount FROM palm_buyers WHERE palm_buyers.affiliate_id IS NOT NULL AND palm_buyers.affiliate_amount IS NOT NULL UNION ALL SELECT palm_buyers.affiliate_id, timestamptz(abstime(palm_buyers.refund_datetim e)) AS date, 'Palm Refund' AS type, 2 AS type_id, - palm_buyers.affiliate_amou nt AS amount Is this the real output or you were bitten by cutpaste wrapping? It doesn't look good to me as is... [several other cases in the rest of the definition] -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) The ability to monopolize a planet is insignificant next to the power of the source ---(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] Release changes
Neil Conway wrote: On Mon, Aug 04, 2003 at 10:47:36AM +0200, Andreas Pflug wrote: 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. Yeah, unfortunately I didn't get a chance to implement this functionality during the 7.4 cycle (and it apparently wasn't important enough for anyone else to do it while I've been away). I'll probably get around to doing it some time before the 7.5 release. The current STATEMENT trigger code is still useful, IMHO -- I think your suggestion that we should remove any mention of this feature from the docs is certainly going too far. Should I submit a patch for the documentation to include a note about what functionality hasn't been implemented yet? That's best, I believe. For people that came from other DBs, not familiar with rules, they should be directed to the advantages of rules. Places that mention triggers and need review: - CREATE TRIGGER - Chapter 36.6 Rules versus Triggers - Chapter 37 Server Programming - Triggers - Chapter 40 PL/PGSQL - Chapter 41 PL/Tcl (not ch. 42 - PL/Perl doesn't support triggers) - Chapter 43 PL/Python Phew! And this list is possibly not complete... Regards, Andreas ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
[HACKERS] dropping a user causes pain (#2)
Hi, I dropped the owner of a table (with no complaints), and now I get this: psql: asdf=# \dt List of relations Schema | Name | Type | Owner +--+---+ public | a1 | table | pg_dump: pg_dump: WARNING: owner of data type a1 appears to be invalid pg_dump: WARNING: owner of table a1 appears to be invalid Didn't there used to be a check that occurred, preventing you from dropping a user who owned objects? Chris ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] threads/UnixWare
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. 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, but it 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Thread-safe configuration option appears to
Larry Rosenman wrote: As soon as a beta tarball shows up, I'll cut changes for UnixWare for --enable-threads, and also to do -D_REENTRANT anyway on UnixWare. OK. What about Kean's change to allow absolute DT_SONAME's? Can that get applied, and used for SCO and UnixWare? Can you verify if it needed only because they honor LD_LIBRARY_PATH on suid executables? If so, I would like to have something that is only in the template file and Makefile.shlib. I think that is possible. -- 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] sql99 compat list
On Mon, Aug 11, 2003 at 09:40:25AM +0800, Christopher Kings-Lynne wrote: Has anyone reviewed the compatibility list for 7.4 yet? I seem to remember something about us having the unique predicate now or something? I hacked up a really simplistic implementation of it, but it wasn't included in 7.4 since it was only half-baked. cursors? I believe I updated the list for the new cursor features, but let me know if I missed anything. -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] TODO items
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 ---(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] 7.4beta1 build problem on unixware
Kurt Roeckx [EMAIL PROTECTED] writes: On Thu, Aug 07, 2003 at 05:20:58PM +0200, [EMAIL PROTECTED] wrote: I have NI_NUMERICHOST defined in netdb.h That's for getnameinfo(). getnameinfo() is older than getaddrinfo() ... If you have that, I assume you have AI_NUMERICHOST in the same file too ... ? Nope, they don't :-(. I committed fixes a day or two ago that seem to take care of this, though we won't know for sure till it's tried on more platforms ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Make check problem.
Kurt Roeckx [EMAIL PROTECTED] writes: What's the point of running a regression tests if it's going to use the old binary? It doesn't, ordinarily. Feel free to trace through the scripts and find out what went wrong. 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
[HACKERS] Farewell
Title: Farewell It's timefor formalacknowledgement that I'm not in The Project any more. I'm not interested in small features/fixes and have no time for big ones. It was this way for very long time and I don't see how/when that could change. My participation in The Project was one of the greatest adventures in my life. Thanks to everyone! Good luck on your ways. And - long live to Postgres!!! Vadim
Re: [HACKERS] TODO items
Tom Lane wrote: 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. Updated as done. I thought Peter did something with this one: * Allow LIKE indexing optimization for non-ASCII locales Yeah, he did. Yes, wording updated and marked as done. -- 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] 7.4Beta1 hang?
On Sat, 09 Aug 2003 21:17:05 -0400 Tom Lane [EMAIL PROTECTED] said something like: Could you supply the relation names corresponding to the relation OIDs appearing in pg_locks, so we can be sure who's processing what? Sure, if you tell me how ;-) I looked at the view definition and that didn't help me much... -- 19:32:24 up 8 days, 12:18, 4 users, load average: 2.07, 2.05, 2.00 pgp0.pgp Description: PGP signature
[HACKERS] Windows on SuSE? 7.4
SuSE 7.3, PostgreSQL cvshead (7.4) This is as far as I've gotten with 7.4. It is built and configured like my 7.3 installation on the same machine. I have built from CVS previously. And the production sources always builds very nice and clean. Nothing runs. gbd output is below. It is balking on loading a suspect library. I ordinarily would suspect some minor permission or configuration issue, but I cannot see one. Joe Conway suggested it might be a problem with the the windows configuration changes. My machine has WINE on it (windows) although I never use it. There really should be no reason for anything to be trying to link in a windows socket library. I don't have time to follow it further right now. But if someone else has a similar configuration and/or wine installed, it would be very helpful to compare 7.4 installations. I can provide config arguments and log if someone would find them useful. gdb bin/postmaster GNU gdb 20010316 Copyright 2001 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-suse-linux... (gdb) run -i -D /local/pghead/data Starting program: /local/pghead/bin/postmaster -i -D /local/pghead/data Program received signal SIGSEGV, Segmentation fault. 0x40099ac5 in dllname () from /usr/lib/libwsock32.so (gdb) bt #0 0x40099ac5 in dllname () from /usr/lib/libwsock32.so #1 0x08121821 in StreamServerPort () #2 0x08150996 in PostmasterMain () #3 0x08123353 in main () #4 0x4010e7ee in __libc_start_main () from /lib/libc.so.6 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
