Re: [HACKERS] Updating psql for features of new FE/BE protocol
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 ...
OK, I figured it out. :-)
It's a fairly short patch in 7.3.3, what do I need to do to submit it
for 7.4?
I also made a minor functional change that may need to be turned into
an additional variant on echo: if ECHO is set to 'queries' and output
is being sent other than to stdout (\o), it echoes the query to the output
file or pipe.
If that's too much of a change and this needs to be a separate option,
I'd suggest something like setting ECHO to 'queryout'. To be complete,
would it need to have a command line equivalent, too?
BTW, I figured out how to direct the output to a separate file each time,
I put the following in .psqlrc:
\o |tee `echo psql_${$}.txt`
--
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
[HACKERS] date parsing
Is this deliberate? usa=# select '1-1-2001'::date; date 2001-01-01 (1 row) usa=# select '1-1--2001'::date; date 2001-01-01 (1 row) usa=# select '1-1---2001'::date; date 2001-01-01 (1 row) usa=# select '1--1--2001'::date; date 2001-01-01 (1 row) 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] [GENERAL] Physical Database Configuration
On Wednesday 25 June 2003 20:49, [EMAIL PROTECTED] wrote: Well, correct solution is to implement tablespaces on which objects like databases, tables and indexes can be put. I've not looked at the SQL standard, but it seems to me like the order should be: Databases Tablespaces Schemas Objects (tables, indexes, functions, etc.) That should be Tablespaces databases schemas objects with each of them implemented as a directory and data files under it. If we could get a quota check propogated in both direction, that would be pretty good, may be a warning when things start getting close to limit. And it really isn't hierarchical. As I understand them (based on my Oracle background), tablespaces, unlike schemas, do NOT create a layer of data abstraction. That is to say, while the same table name can exist in multiple schemas, only one instance of a given table name within a given schema can exist, regardless of what tablespace it is in. Well, if same table name exists in two different databases under same tablespace, what's the problem? Whether or not two databases can share tablespaces isn't clear to me, though as a DBA I can think of good reasons why they probably shouldn't do so, I'm not sure if that is an absolute. Well, I would say they should be allowed to. Shridhar ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Missing 7.3.3 cvs tag
I don't see a tag for in cvs for the 7.3.3 release. Kris Jurka ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] row description for domain in 7.4
On Wednesday, June 25, 2003, at 10:42 PM, Tom Lane wrote: 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. Hi Tom, Can you give me a pointer on where to find the archived discussions? I have tried all the reasonable keywords I can think of in the archive search, but I can't seem to find anything. Thanks, John DeSoi, Ph.D. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] recursive queries
Tom Lane once said: 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. Yeah, I had originally thought that I would be able to get it done, but only sporadic development time leaves me in the usual where was I?-oh yeah-_this_ is what I was going to do next time-sink and I haven't progressed as much as I had wanted. I had been attempting to get the non-recursive case in before 7.4, but that's not going to happen either. Sometime this summer for sure. Sorry. 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] date parsing
Christopher Kings-Lynne [EMAIL PROTECTED] writes: Is this deliberate? usa=# select '1-1--2001'::date; [works] The guys who might actually be able to tell you whether it was an intended behavior are long gone. But I don't see any particular problem with it. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] row description for domain in 7.4
John DeSoi [EMAIL PROTECTED] writes: On Wednesday, June 25, 2003, at 10:42 PM, Tom Lane wrote: 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. Can you give me a pointer on where to find the archived discussions? I Searching for domain and protocol seems to turn up most of the relevant messages, eg http://fts.postgresql.org/db/msg.html?mid=1062840 http://fts.postgresql.org/db/msg.html?mid=1046504 http://fts.postgresql.org/db/msg.html?mid=1365382 http://fts.postgresql.org/db/msg.html?mid=1368327 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] [GENERAL] Physical Database Configuration
That should be Tablespaces databases schemas objects with each of them implemented as a directory and data files under it. If we could get a quota check propogated in both direction, that would be pretty good, may be a warning when things start getting close to limit. I disagree. Just as you can have multiple schemas within one database you can have multiple tablespaces within one database. And the tablespace is irrelevant as far as specifying an object is concerned. A fully qualified object would be: database.schema.object, not tablespace.database.schema.object or database.tablespace.schema.object. -- 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] [GENERAL] Physical Database Configuration
[EMAIL PROTECTED] writes: I disagree. Just as you can have multiple schemas within one database you can have multiple tablespaces within one database. And the tablespace is irrelevant as far as specifying an object is concerned. A fully qualified object would be: database.schema.object, not tablespace.database.schema.object or database.tablespace.schema.object. Right, the tablespace structure is really orthogonal to the database/schema structure. I would envision tablespaces as being named by database-cluster-wide names, just as users and groups are. Any given table could be placed in any tablespace (although perhaps we want to invent some permission mechanism here). Physically a tablespace is a directory with sub-directories for databases under it --- so $PGDATA/base plays the role of the default tablespace for a cluster. (The reason you need per-database sub-directories is mostly to support DROP DATABASE, which has to be able to nuke a database without knowing exactly what's in it.) But this structure doesn't have anything to do with the logical structure of the database cluster. There are a bunch of interesting locking issues to be solved, but the storage layout ideas are pretty clear in my mind. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] Physical Database Configuration
On Thursday 26 June 2003 20:22, Tom Lane wrote: [EMAIL PROTECTED] writes: I disagree. Just as you can have multiple schemas within one database you can have multiple tablespaces within one database. And the tablespace is irrelevant as far as specifying an object is concerned. A fully qualified object would be: database.schema.object, not tablespace.database.schema.object or database.tablespace.schema.object. Right, the tablespace structure is really orthogonal to the database/schema structure. Well, consider this. Keep in mind that all of them are directories.. Tablespace1 db1 schema1 table1 table2 db2 schema1 table1 table2 Tablespace2 db1 schema1 index1 Now, unlike Oracle, I don't remember anybody suggesting to get away with $PGDATA entirely because we have tablespaces. $PGDATA is going to be available and will continue to host at least one directory for each database. So postgresql now where to find all tablespaces that hosts that particular database related object. Certainly does not sound impossible or illogical to me. And I agree. The paradigm, 'A tablespace can host multiple database and a database can span across multiple tablespaces' is absolutely arthgonal. Convoluted is what I would term it. But hey, it's the most flexible one!!..:-) Physically a tablespace is a directory with sub-directories for databases under it --- so $PGDATA/base plays the role of the default tablespace for a cluster. (The reason you need per-database sub-directories is mostly to support DROP DATABASE, which has to be able to nuke a database without knowing exactly what's in it.) But this structure doesn't have anything to do with the logical structure of the database cluster. Well, with above proposal, drop database should be as simple. It's just that it would be more than one `rm -rf`rather than just one. HTH Shridhar ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] Physical Database Configuration
Shridhar Daithankar [EMAIL PROTECTED] writes: Well, consider this. Keep in mind that all of them are directories.. I can see no reason that we'd want a level of directory associated with schemas... Well, with above proposal, drop database should be as simple. It's just that it would be more than one `rm -rf`rather than just one. Right, there would be potentially one per tablespace. The key point here is that the tablespace definitions are known cluster-wide, so a DROP DATABASE x command running in database y would still be able to figure out which subdirectories it needs to zap. regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] Physical Database Configuration
On Thursday 26 June 2003 21:29, Tom Lane wrote: Shridhar Daithankar [EMAIL PROTECTED] writes: Well, consider this. Keep in mind that all of them are directories.. I can see no reason that we'd want a level of directory associated with schemas... Moving a multi-hundreds-of-GB table across schemas would be sooo easy..:-) I don't know how difficult/time consuming that is right now. Shouldn't be actually if PG updates the schema contents in it's catalog but anyway.. I just put it for clarification. If PG can do everything directory has to offer, well, we don't need directory for schemas. Shridhar ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Physical Database Configuration
Shridhar Daithankar [EMAIL PROTECTED] writes: On Thursday 26 June 2003 21:29, Tom Lane wrote: I can see no reason that we'd want a level of directory associated with schemas... Moving a multi-hundreds-of-GB table across schemas would be sooo easy..:-) No, it would be harder. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] [GENERAL] Physical Database Configuration
Well, with above proposal, drop database should be as simple. It's just that it would be more than one `rm -rf`rather than just one. Right, there would be potentially one per tablespace. The key point here is that the tablespace definitions are known cluster-wide, so a DROP DATABASE x command running in database y would still be able to figure out which subdirectories it needs to zap. It sounds like you envision tablespaces (or at least the default tablespace) as being above databases in some contexts. Reducing other tablespaces to mere subdirectories under the 'base' directory for a database sounds like a practical implementation measure. I presume that the 'global' directory is for stuff that is not specific to any one database within a database cluster. If so, there is an inconsistency in the current directory structure in that SOME global information is in the main /usr/local/pgsql/data directory (or equivalent) while other global information is in the global subdirectory. Being able to zap a database with one or more 'rm -rf' commands assumes that there will be files from just ONE database permitted in any given tablespace, and ONLY files from that database. The former is probably a good thing to require and enforce, the latter is unenforcable but probably still advisable. Is this doable within the time frame for the 7.4 feature freeze? -- Mike Nolan ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] [GENERAL] Physical Database Configuration
On Thursday 26 June 2003 21:56, [EMAIL PROTECTED] wrote: Is this doable within the time frame for the 7.4 feature freeze? Good question. If it gets in 7.4, that would be more than a killer feature to put against 7.4 release, with due respect to all other enhancements in progress.. Shridhar ---(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] ECPG and bytea
Guys, surely some one's done this before? I've tried using PQescapeBytea too, but still get (slightly) different output. If I try and insert \x02\x01\x02\x03\x04hello\x05\x64\x99\x45 I get (int values of chars printed): INSERT: 2 1 2 3 4 104 101 108 108 111 5 100 -103 69 SELECT: 2 1 2 3 4 104 101 108 108 111 5 100 92 50 51 49 69 hoping someone has a quick answer... if not I'll post a full source example and look into it more... Thanks, L. ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
Tom Lane wrote: Peter Eisentraut [EMAIL PROTECTED] writes: Thomas Swan writes: Have you considered something similar to the Mozilla tinderbox approach where you have a daemon checkout the cvs, compile, run regression tests, and report a status or be able to report a status? Even if you could achieve near complete coverage of the platforms, platform versions, and auxilliary software versions and combinations that PostgreSQL runs with, in most cases, something breaks on a new version or combination of these things. Still, whenever we're doing something that interacts at all with the OS, it seems we get breakages that don't show in the original author's testing, but only pop up days to months later when some beta tester tries the code on platform P or using option Q. The current difficulties with the IPv6 patches are a fine case in point. If we could get feedback more easily about whether a proposed patch compiles and passes regression on a variety of platforms, we could reduce the pain involved by a great deal, simply because the problems could be fixed while the code is still fresh in mind. I don't think there is any company involved with Postgres that is willing to commit the resources to run a Mozilla-style tinderbox setup singlehanded. But I wonder whether we couldn't set up something that is community-based: get a few dozen people with different platforms to volunteer to check the code regularly on their own machines. I'm imagining a cron job that fires daily in the wee hours, pulls the latest CVS tip, does make distclean; configure; make; make check, and mails the results to someplace that puts 'em up on our website. It's possible that we could adapt the tinderbox software to work this way, but even if we had to write our own, it seems like a fairly simple task. And it'd give *much* better feedback on porting problems than we have now. Sure, there will always be corner cases you don't catch, but the first rule of testing is the sooner you find a bug the cheaper it is to fix. Is it possible the sourceforge compile farms could be used for some of the automated testing? I'm not sure how that system works, but it could be worth looking into. 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]) ---(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
[EMAIL PROTECTED] writes: Being able to zap a database with one or more 'rm -rf' commands assumes that there will be files from just ONE database permitted in any given tablespace, and ONLY files from that database. I said no such thing. Look at the structure again: $PGDATA/base/dboid/...stuff... sometablespace/dboid/...stuff... othertablespace/dboid/...stuff... DROPDB needs to nuke somepath/dboid/ for each tablespace's associated somepath. The other design simplifies DROPDB at the cost of increased complexity for every other tablespace management operation, since you'd need to cope with a symlink in each database for each tablespace. Also, this scheme is at least theoretically amenable to a symlink-free implementation, though I personally don't give a darn whether tablespaces are supported on Windows and thus wouldn't expend the extra effort needed to keep track of full paths. I'd want $PGDATA/tablespaces/tboid to be a symlink to the root of the tablespace with a given OID, and then the actual pathname used to access a table in tablespace tboid, database dboid, table filenode rfoid would look like $PGDATA/tablespaces/tboid/dboid/rfoid But a Windoze version could in theory keep track of tablespace locations directly, and replace the first part of this path with the actual tablespace location. If we put tablespaces under directories then the facility has zero functionality without symlinks, because you couldn't actually do anything to segregate stuff within a database across different devices. BTW, we'd probably remove $PGDATA/base in favor of $PGDATA/tablespaces/N for some fixed-in-advance N that is the system tablespace, and we'd require all system catalogs to live in this tablespace --- certainly at least pg_class and its indexes. Otherwise you have circularity problems in finding the catalogs ... 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] ECPG and bytea
Lee Kindness wrote: Guys, surely some one's done this before? I've tried using PQescapeBytea too, but still get (slightly) different output. If I try and insert \x02\x01\x02\x03\x04hello\x05\x64\x99\x45 I get (int values of chars printed): INSERT: 2 1 2 3 4 104 101 108 108 111 5 100 -103 69 SELECT: 2 1 2 3 4 104 101 108 108 111 5 100 92 50 51 49 69 hoping someone has a quick answer... if not I'll post a full source example and look into it more... I don't know much about ecpg, but here are some thoughts: regression=# select x'99'::int; int4 -- 153 (1 row) regression=# select chr(-103) = chr(153); ?column? -- t (1 row) So the insert looks correct but affected by signed vs unsigned char somehow. As far as the select goes, I'm wondering if your database is using UTF8 encoding or something like that. That would explain a high bit character getting converted to 4 bytes, I think. HTH, Joe ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
Thomas Swan [EMAIL PROTECTED] writes: Is it possible the sourceforge compile farms could be used for some of the automated testing? I'm not sure how that system works, but it could be worth looking into. The last time I used it (which admittedly was a year or two back), they didn't really have a very wide range of platforms available. And I don't think they were offering cron access on the farm machines, so this would be much more painful to automate than work done locally on contributors' machines. 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] Table partitioning question.
I seem to recall that Table partitioning used to be on the *urgent* heading of the ToDo list. Now I see it is under misc. As people who are needing to move away from Oracle due to cost restrictions, I wanted to know how much work, or what the status is of this option. Please respond asap if possible. I have to give my VP info on this relatively soon. Sorry for the urgent nature. -- Austin Gonyou [EMAIL PROTECTED] Coremetrics, Inc. ---(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] [GENERAL] pg_dump all tables in 7.3.X
Oh, if it's by design then the pg_dump --help text should be updated correspondingly. The online doco is already correct. Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: We are trying to do an all tables dump using the 7.3.3 pg_dump, but are getting no love. The pg_dump command which worked before, in 7.2, no longer returns any tables: pg_dump -t * dbname Is this by design, or by accident? By design. Just omit the -t switch if you want all tables. (* is a legal table name, if perhaps not a very bright choice, so the old behavior was really not consistent.) regards, tom lane -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_guc
Fernando, We have a server side GUI utility that among other things let us configure GUC variables. We badly need to know what variables exist in the specific backend version, which are the min and max values and if possible a description. The option is to hardwire these things into the code which is very awkward (and we want it to work with different backend versions, backends compiled differently etc.). As the new GUC List guru, I will send you a list in PDF or SXW format which covers 7.3 and 7.4 this weekend.If you database it, I would love to have the table back in return. Please note that the actual maximum value for many variables is much larger than the practical maximum value. For example, RANDOM_PAGE_COST is only limited to INT MAX on the host OS, even though all practical values are between 1 and 10. -- -Josh Berkus Aglio Database Solutions San Francisco ---(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] row description for domain in 7.4
Tom, Thanks for helping me find the previous discussion. 2) Better support for domains. Currently the jdbc driver is broken with regards to domains (although no one has reported this yet). The driver will treat a datatype that is a domain as an unknown/unsupported datatype. It would be great if the T response included the 'base' datatype for a domain attribute so that the driver would know what parsing routines to call to convert to/from the text representation the backend expects. To me this seems completely wrong. The whole point of getting the domain is so that I can know how I should parse the result coming from the server. If I use a text domain, I can't distinguish the domain column from any other text column and perform some other kind of processing on the data. If it remains as is, then the front end has to look up every column on every request to see if that column corresponds to some domain. It could possibly be cached to some degree, but it seems like dropping/adding columns could result in the same a table oid, column number pair having the same base type but a different domain. As implemented previously, the front end only has to make one request, one time, to determine the base type of the domain OID. - base type OID instead of user type OID. Might break some clients dealing with special types. ODBC users won't notice. - a postgresql.conf option to tell the backend to use base type OID or user type OID. Would catch most cases. - a connection specific setting to tell the backend to use base type OID or user type OID. For concurrent ODBC and weird clients use. - base type additionally in the RowDescription message. Obviously, this would break the 7.3 protocol. My vote would be to restore the previous behavior and add connection-specific setting for clients that need it. I don't think a postgresql.conf option (alone) is viable because users might want to use different kinds of front ends for the same server. Best, John DeSoi, Ph.D. ---(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
Shridhar Daithankar [EMAIL PROTECTED] writes: On Thursday 26 June 2003 21:56, [EMAIL PROTECTED] wrote: Is this doable within the time frame for the 7.4 feature freeze? Good question. ROTFL... the answer is no. Feature freeze is Tuesday, people. In practice, the time to start coding new stuff is already long past. Especially major new stuff. If you start now you might have something done for 7.5. Forgive us, Tom, we are still learning how the cycle works. (Or at least I am.) I am also probably grossly underestimating the pervasiveness of implementing tablespaces. -- Mike Nolan ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] pg_dump all tables in 7.3.X
Paul Ramsey [EMAIL PROTECTED] writes: Oh, if it's by design then the pg_dump --help text should be updated correspondingly. The online doco is already correct. Hm. Wait a minute --- I was thinking of 7.4 not 7.3. The * hack does appear to still be there in the 7.3 source code. Are you sure you're typing the command just like that? pg_dump -t * dbname regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] pg_dump all tables in 7.3.X
Entirely sure: [EMAIL PROTECTED] pg_dump]$ which pg_dump /opt/pgsql73/bin/pg_dump [EMAIL PROTECTED] pg_dump]$ pg_dump -t * pramsey -- -- PostgreSQL database dump -- [EMAIL PROTECTED] pg_dump]$ Tom Lane wrote: Paul Ramsey [EMAIL PROTECTED] writes: Oh, if it's by design then the pg_dump --help text should be updated correspondingly. The online doco is already correct. Hm. Wait a minute --- I was thinking of 7.4 not 7.3. The * hack does appear to still be there in the 7.3 source code. Are you sure you're typing the command just like that? pg_dump -t * dbname regards, tom lane -- __ / | Paul Ramsey | Refractions Research | Email: [EMAIL PROTECTED] | Phone: (250) 885-0632 \_ ---(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] pg_dump all tables in 7.3.X
Paul Ramsey [EMAIL PROTECTED] writes: Entirely sure: Hmph. There must be some bug in the 7.3 code for it then. Since we've already ripped out that code for 7.4, I'm not too excited about finding the problem... regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] A portable code question
In the little fix I came up with for psql last night, I need to be able
to ensure that something sent to a pipe (and then to stdout) completes
before issuing the prompt directly to stdout.
I did this with: system ('sleep 1');, but I'm fairly sure that is
not portable nor does it ENSURE completion.
What's the proper way to do this? And what's a good book on writing
portable code?
--
Mike Nolan
---(end of broadcast)---
TIP 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
Nigel J. Andrews wrote: On Thu, 26 Jun 2003, Thomas Swan wrote: Is it possible the sourceforge compile farms could be used for some of the automated testing? I'm not sure how that system works, but it could be worth looking into. Isn't the sourceforge license very scary and along the lines of whatever you put on here we own it's just we tend not to persue that at the moment as there's not much money in it for us but that doesn't stop us from claiming it at some indeterminate time in the future? If it's that intrusive, then it was a bad idea. But, I didn't find anything like that on their Terms of Use http://sourceforge.net/docman/display_doc.php?docid=6048group_id=1 page. The compiler farm has a relatively small number of platforms, but perhaps it would be enough to get started with at least verifying an automated test would work. See Guide to the Sourceforge Compile Farm http://sourceforge.net/docman/display_doc.php?docid=762group_id=1. In terms of implementation, I was thinking of something like the following. * clean the source, destination directories * pull latest CVS tip down. * record environment / installed packages * loop - on different options ( w/ or w/o krb5, w/ or w/o ssl, etc. ) o make clean o configure with sets of options o compile + log messages + analyze errors ( perhaps gather statitistics: warnings, failures, notices, etc.) o (run / install) if successful o run tests + output results (perhaps to HTML) + compare results with expected + record differences if any | gather aggregate information o uninstall / clean up * end loop Perhaps there could be an occasion where the test would be able to put in a corrupt WAL or a corrupt table to do regression tests for recovery of errors. Of course, these are just ideas and I'm not sure how practical it is to do any of them. I just am really concerned about the uninstall/clean up phase and how that can be done in an orderly fashion. Unless the process can start from a clean state again, then it won't be valid. At one point I had even given thought, vainly, to purchasing VMWare for such an occasion. Suggestions? ---(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 portable code question
Assuming you're using file streams to write to the pipe, fflush() will do
the trick.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, June 26, 2003 2:20 PM
To: pgsql hackers list
Subject: [HACKERS] A portable code question
In the little fix I came up with for psql last night, I need to be able
to ensure that something sent to a pipe (and then to stdout) completes
before issuing the prompt directly to stdout.
I did this with: system ('sleep 1');, but I'm fairly sure that is
not portable nor does it ENSURE completion.
What's the proper way to do this? And what's a good book on writing
portable code?
--
Mike Nolan
---(end of broadcast)---
TIP 8: explain analyze is your friend
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
I know I'm new to this list, but is OSDL's testing capabilities out of the question? On Thu, 2003-06-26 at 13:48, Thomas Swan wrote: Nigel J. Andrews wrote: On Thu, 26 Jun 2003, Thomas Swan wrote: Is it possible the sourceforge compile farms could be used for some of the automated testing? I'm not sure how that system works, but it could be worth looking into. Isn't the sourceforge license very scary and along the lines of whatever you put on here we own it's just we tend not to persue that at the moment as there's not much money in it for us but that doesn't stop us from claiming it at some indeterminate time in the future? If it's that intrusive, then it was a bad idea. But, I didn't find anything like that on their Terms of Use http://sourceforge.net/docman/display_doc.php?docid=6048group_id=1 page. The compiler farm has a relatively small number of platforms, but perhaps it would be enough to get started with at least verifying an automated test would work. See Guide to the Sourceforge Compile Farm http://sourceforge.net/docman/display_doc.php?docid=762group_id=1. ... -- Austin Gonyou [EMAIL PROTECTED] Coremetrics, Inc. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] A portable code question
Or if you want this behaviour all the time, one call of
setvbuf(mypipe,(char *)0,_IONBF,0);
should do the trick (much easier than remebering to have to call fflush()
all the time).
If not using streams, and just calling write(), then you probably don't have
to worry.
andrew
BTW, system('sleep 1'); probably won't compile, and 'system(sleep 1);'
is bad news. Try man 3 sleep for more info.
Assuming you're using file streams to write to the pipe, fflush() will
do the trick.
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf Of
[EMAIL PROTECTED]
Sent: Thursday, June 26, 2003 2:20 PM
To: pgsql hackers list
Subject: [HACKERS] A portable code question
In the little fix I came up with for psql last night, I need to be
able to ensure that something sent to a pipe (and then to stdout)
completes before issuing the prompt directly to stdout.
I did this with: system ('sleep 1');, but I'm fairly sure that is
not portable nor does it ENSURE completion.
What's the proper way to do this? And what's a good book on writing
portable code?
--
Mike Nolan
---(end of
broadcast)--- TIP 8: explain analyze is your
friend
---(end of
broadcast)--- TIP 7: don't forget to increase
your free space map settings
---(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
On Thu, 2003-06-26 at 15:00, Austin Gonyou wrote: I know I'm new to this list, but is OSDL's testing capabilities out of the question? From what I've seen, OSDL is only concerned with a very very small set of platforms (Linux in a couple of configurations). -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Two weeks to feature freeze
DOH!. YesYou're right I totally forgot about that. My apologies. I believe though, that there is a HP testing lab that is somewhat like OSDL, in that they offer OSS free services and many platforms to run on. (used to be compaq's developer testdrive sort of program) I believe it still exists. -Original Message- From: Rod Taylor [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 3:06 PM To: Austin Gonyou Cc: Thomas Swan; Nigel J. Andrews; Tom Lane; PostgreSQL Development Subject: Re: Two weeks to feature freeze On Thu, 2003-06-26 at 15:00, Austin Gonyou wrote: I know I'm new to this list, but is OSDL's testing capabilities out of the question? From what I've seen, OSDL is only concerned with a very very small set of platforms (Linux in a couple of configurations). -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
* clean the source, destination directories * pull latest CVS tip down. Why tip? Lets simply update the current source tree to the most current of whatever branch they had checked out initially. Running it on older stable branches is just as useful. * record environment / installed packages Virtually impossible, especially if people take to installing some items by hand (we want to test them as well). Recording the configure output on the other hand would be quite useful. * loop - on different options ( w/ or w/o krb5, w/ or w/o ssl, etc. ) o make clean o configure with sets of options o compile + log messages + analyze errors ( perhaps gather statitistics: warnings, failures, notices, etc.) Any warnings, failures, etc. aside from what is in the 'known' file should be reported -- makes sense. o (run / install) if successful o run tests + output results (perhaps to HTML) + compare results with expected + record differences if any | gather aggregate information Standard regression tests should suffice. Any non-ignored errors reported. o uninstall / clean up Skip this. Cleanup prior to the run. If something is wrong, we may need additional information from the environment. * end loop Perhaps there could be an occasion where the test would be able to put in a corrupt WAL or a corrupt table to do regression tests for recovery of errors. These would be interesting extensions to the standard regression suite -- but perhaps require a flag Of course, these are just ideas and I'm not sure how practical it is to do any of them. I just am really concerned about the uninstall/clean up phase and how that can be done in an orderly fashion. Unless the process can start from a clean state again, then it won't be valid. At I've not tried, but if PostgreSQL can do an 'out of tree' compile it could make it much easier. That said, poor cleanup would be a result of a broken make clean. one point I had even given thought, vainly, to purchasing VMWare for such an occasion. Suggestions? Skip VMWare. Find a few volunteers to cron the script (I'll volunteer). I think we should replace Bruce's pgtest script with this one -- with an argument to accept the email address to report to for FAILING cases. Success isn't very interesting if it runs regularly. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Two weeks to feature freeze
On Thu, 2003-06-26 at 16:09, Gonyou, Austin wrote: DOH!. YesYou're right I totally forgot about that. My apologies. I believe though, that there is a HP testing lab that is somewhat like OSDL, in that they offer OSS free services and many platforms to run on. (used to be compaq's developer testdrive sort of program) I believe it still exists. I've been on Compaq's testdrive boxes before -- very nice. But I'm not sure we want to use those for a testing platform. More to the point, if OSDL benchmarks keep coming along we should have a variety of PostgreSQL benchmarks to choose from. Adding a regression test for performance would be a wise thing to do, but will require dedicated hardware for good numbers (especially if run nightly). Thomas had a good start in mind. Hopefully we can extend it a little once it has been started. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] Two weeks to feature freeze
-Original Message- From: Rod Taylor [mailto:[EMAIL PROTECTED] Sent: Thursday, June 26, 2003 3:33 PM To: Gonyou, Austin Cc: Thomas Swan; Nigel J. Andrews; Tom Lane; PostgreSQL Development Subject: RE: Two weeks to feature freeze On Thu, 2003-06-26 at 16:09, Gonyou, Austin wrote: DOH!. YesYou're right I totally forgot about that. My apologies. I believe though, that there is a HP testing lab that is somewhat like OSDL, in that they offer OSS free services and many platforms to run on. (used to be compaq's developer testdrive sort of program) I believe it still exists. I've been on Compaq's testdrive boxes before -- very nice. But I'm not sure we want to use those for a testing platform. Agreed, but the point was, there is a developer side where developers can test their code for a longer period of time in a more lab-like environment, much the same way as OSDL schedules their testing, etc, but you can try stuff on Alpha and x86, run windows, solaris, Tru64, etc. More to the point, if OSDL benchmarks keep coming along we should have a variety of PostgreSQL benchmarks to choose from. Adding a regression test for performance would be a wise thing to do, but will require dedicated hardware for good numbers (especially if run nightly). Understood and I concurr, I just didn't think about the testing scope of OSDL. Thomas had a good start in mind. Hopefully we can extend it a little once it has been started. I agree, just trying to offer something I thought was more valuable than it may have been. :) -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] A portable code question
Assuming you're using file streams to write to the pipe, fflush() will do
the trick.
The problem is that the pipe (from \o |tee ) is intermingling writes
to stdout by tee with direct writes to stdout from within psql.
I do issue a fflush, because that's necessary to make the pipe do its
thing, but the next line of code also does a write to stdout and the pipe
generally doesn't have time to complete that write to stdout, resulting
in intermingled output. (fflush makes sure the pipe GETS the stream,
it doesn't wait around to make sure it's DONE with it, probably because
there's no way for whatever the pipe calls to report back when it is done.)
This is a bit of a hack, but adding an option to the \o code so that it
writes simultaneously to the pipe and to stdout instead of using tee
looks like a lot more work, especially since the code appears to have a
couple of other places where intermingling to stdout is possible,
especially if readline is used.
Throwing in system('sleep 1'); was the way I resolved the timing
question here, but that may not be portable enough for inclusion into
the code base.
--
Mike Nolan
---(end of broadcast)---
TIP 8: explain analyze is your friend
[HACKERS] ECPG thread success (kind of) on Linux
On Thu, 26 Jun 2003 11:19 am, Philip Yarra wrote: there appears to still be a problem occurring at EXEC SQL DISCONNECT con_name. I'll look into it tonight if I can. I did some more poking around last night, and believe I have found the issue: RedHat Linux 7.3 (the only distro I have access to currently) ships with a fairly challenged pthreads inplementation. The default mutex type (which you get from PTHREAD_MUTEX_INITIALIZER) is, according the the man page, PTHREAD_MUTEX_FAST_NP which is not a recursive mutex. If a thread owns a mutex and attempts to lock the mutex again, it will hang. By replacing PTHREAD_MUTEX_INITIALIZER with PTHREAD_MUTEX_RECURSIVE_NP for the two mutexes that are used recursively (debug_mutex and connections_mutex) I got my sample app to work flawlessly on Linux RedHat 7.3 Sadly, the _NP suffix is used to indicate non-portable, so of course my FreeBSD box steadfastly refused to compile it. Darn. The correct way to do this appears to be: pthread_mutexattr_t *mattr; pthread_mutexattr_settype(mattr, PTHREAD_MUTEX_RECURSIVE); (will verify this against FreeBSD when I get home, and Tru64 man page indicates support for this too, so I'll test that later). It won't work on RedHat Linux 7.3... I guess something like: #ifdef DODGY_PTHREADS #define PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP #endif might do it... if we could detect the problem during configure. How is this sort of detection handled in other cases (such as long long, etc)? The other solution I can think of is to eradicate the two recursive locks I found. One is simple: ECPGlog calls ECPGdebug, which share debug_mutex - it ought to be okay to use different mutexes for each of these functions (there's a risk someone might call ECPGdebug while someone else is running through ECPGlog, but I think it is less likely, since it is a debug mechanism.) The second recursive lock I found is ECPGdisconnect calling ECPGget_connection, both of which share a mutex. Would it be okay if we did the following: ECPGdisconnect() still locks connections_mutex, but calls ECPGget_connection_nr() instead of ECPGget_connection() ECPGget_connection() becomes a locking wrapper, which locks connections_mutex then calls ECPGget_connection_nr() ECPGget_connection_nr() is a non-locking function which implements what ECPGget_connection() currently does. I'm not sure if this sort of thing is okay (and there may be other recursive locking scenarios that I haven't exercised yet). What approach should I take? I'm leaning towards eradicating recursive locks, unless someone has a good reason not to. All this does kinda raise the interesting question of why it worked at all on FreeBSD... probably different scheduling and blind luck, I suppose. FreeBSD 4.8 must have PTHREAD_MUTEX_RECURSIVE as default mutex type. I'm a bit concerned about FreeBSD 4.2 though - I noticed (before I blew it away in favour of 4.8) that its pthreads implementation came from a package called linuxthreads.tgz - it might have inherited the same problematic behaviour. Could someone with access to or knowledge of FreeBSD 4.2 check what the default mutex type is there? Regards, Philip. I can just see the ad for 7.3's pthreads impementation Fast mutexes: zero to deadlock in 6.9 milliseconds! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Two weeks to feature freeze
On Thu, 26 Jun 2003, Thomas Swan wrote: Of course, these are just ideas and I'm not sure how practical it is to do any of them. I just am really concerned about the uninstall/clean up phase and how that can be done in an orderly fashion. Unless the process can start from a clean state again, then it won't be valid. At one point I had even given thought, vainly, to purchasing VMWare for such an occasion. Suggestions? Personally ... if you could build up the test script, I think there are enough ppl with more platforms on these lists that would be willing ot run it ... the problem isn't getting the farm together, its coming up with the automated (or even semi-automated) tests :( ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Two weeks to feature freeze
On Thu, 26 Jun 2003, Rod Taylor wrote: I think we should replace Bruce's pgtest script with this one -- with an argument to accept the email address to report to for FAILING cases. Success isn't very interesting if it runs regularly. that was why I suggested getting it into the tree ... to at least give a starting point to work from ... and I have at least one machine right now that I can run such tests on ... Dual PII with FreeBSD 5.x-CURRENT on her ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Two weeks to feature freeze
The Hermit Hacker wrote: On Thu, 26 Jun 2003, Thomas Swan wrote: Of course, these are just ideas and I'm not sure how practical it is to do any of them. I just am really concerned about the uninstall/clean up phase and how that can be done in an orderly fashion. Unless the process can start from a clean state again, then it won't be valid. At one point I had even given thought, vainly, to purchasing VMWare for such an occasion. Suggestions? Personally ... if you could build up the test script, I think there are enough ppl with more platforms on these lists that would be willing ot run it ... the problem isn't getting the farm together, its coming up with the automated (or even semi-automated) tests :( I'll see what I can do... my shell script skills are pretty good, but I'm not sure how to handle the noting changes in the gcc output. My best guess is to just do it a couple of times and force something to change (make an intentional mistake) and see if it can catch it, or at least what changes. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] ECPG thread success (kind of) on Linux
According to POSIX 1003.1c-1995, no such mutex-altering function exists. pthread_mutexattr_get/settype(...) functions are defined by X/Open XSH5 (Unix98). I would suggest writing a wrapper for OSs that don't implement recursive locks (it's easy enough to make your own implementation- just check pthread_self() before deciding whether to lock the mutex- potentially again). Either that or the recursive locks can be eliminated. Just for the record, OS X, Solaris 5.8, FreeBSD 4.8, and LinuxThreads support the UNIX98 version, so perhaps this isn't so important after all. On Thursday, June 26, 2003, at 08:45 PM, Philip Yarra wrote: On Thu, 26 Jun 2003 11:19 am, Philip Yarra wrote: there appears to still be a problem occurring at EXEC SQL DISCONNECT con_name. I'll look into it tonight if I can. I did some more poking around last night, and believe I have found the issue: RedHat Linux 7.3 (the only distro I have access to currently) ships with a fairly challenged pthreads inplementation. The default mutex type (which you get from PTHREAD_MUTEX_INITIALIZER) is, according the the man page, PTHREAD_MUTEX_FAST_NP which is not a recursive mutex. If a thread owns a mutex and attempts to lock the mutex again, it will hang. By replacing PTHREAD_MUTEX_INITIALIZER with PTHREAD_MUTEX_RECURSIVE_NP for the two mutexes that are used recursively (debug_mutex and connections_mutex) I got my sample app to work flawlessly on Linux RedHat 7.3 Sadly, the _NP suffix is used to indicate non-portable, so of course my FreeBSD box steadfastly refused to compile it. Darn. The correct way to do this appears to be: pthread_mutexattr_t *mattr; pthread_mutexattr_settype(mattr, PTHREAD_MUTEX_RECURSIVE); (will verify this against FreeBSD when I get home, and Tru64 man page indicates support for this too, so I'll test that later). It won't work on RedHat Linux 7.3... I guess something like: #ifdef DODGY_PTHREADS #define PTHREAD_MUTEX_RECURSIVE = PTHREAD_MUTEX_RECURSIVE_NP #endif might do it... if we could detect the problem during configure. How is this sort of detection handled in other cases (such as long long, etc)? The other solution I can think of is to eradicate the two recursive locks I found. One is simple: ECPGlog calls ECPGdebug, which share debug_mutex - it ought to be okay to use different mutexes for each of these functions (there's a risk someone might call ECPGdebug while someone else is running through ECPGlog, but I think it is less likely, since it is a debug mechanism.) The second recursive lock I found is ECPGdisconnect calling ECPGget_connection, both of which share a mutex. Would it be okay if we did the following: ECPGdisconnect() still locks connections_mutex, but calls ECPGget_connection_nr() instead of ECPGget_connection() ECPGget_connection() becomes a locking wrapper, which locks connections_mutex then calls ECPGget_connection_nr() ECPGget_connection_nr() is a non-locking function which implements what ECPGget_connection() currently does. I'm not sure if this sort of thing is okay (and there may be other recursive locking scenarios that I haven't exercised yet). What approach should I take? I'm leaning towards eradicating recursive locks, unless someone has a good reason not to. All this does kinda raise the interesting question of why it worked at all on FreeBSD... probably different scheduling and blind luck, I suppose. FreeBSD 4.8 must have PTHREAD_MUTEX_RECURSIVE as default mutex type. I'm a bit concerned about FreeBSD 4.2 though - I noticed (before I blew it away in favour of 4.8) that its pthreads implementation came from a package called linuxthreads.tgz - it might have inherited the same problematic behaviour. Could someone with access to or knowledge of FreeBSD 4.2 check what the default mutex type is there? Regards, Philip. I can just see the ad for 7.3's pthreads impementation Fast mutexes: zero to deadlock in 6.9 milliseconds! ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] AgentM [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Two weeks to feature freeze
The Hermit Hacker wrote: 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? Yes, I am (how hard can it be?, he asks himself, knowing all the while that it's a really bad idea to be asking that question. :-). But I haven't the faintest idea of how or where to even start, so pointers would be appreciated. -- Kevin Brown [EMAIL PROTECTED] ---(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 Thu, 26 Jun 2003, Kevin Brown wrote: 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? Yes, I am (how hard can it be?, he asks himself, knowing all the while that it's a really bad idea to be asking that question. :-). But I haven't the faintest idea of how or where to even start, so pointers would be appreciated. Which, of course, is always the fun part ... I believe Thomas is going to be starting to work on test scripts, so you might want to co-ordinate with him ... ---(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
On Thu, 26 Jun 2003, Kevin Brown wrote: The Hermit Hacker wrote: 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? Yes, I am (how hard can it be?, he asks himself, knowing all the while that it's a really bad idea to be asking that question. :-). But I haven't the faintest idea of how or where to even start, so pointers would be appreciated. Create/modify a script to automate some kind of download/sync, test and send failure results somewhere. Make it extensible, so that other tests can be easily added -- preferable in a self contained way. It should grow from there. Gavin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] ECPG thread success (kind of) on Linux
On Fri, 27 Jun 2003 11:58 am, AgentM wrote: According to POSIX 1003.1c-1995, no such mutex-altering function exists. Thanks for the info - useful to know. lock the mutex- potentially again). Either that or the recursive locks can be eliminated. Avoiding recursive locks is my preference - the only two I have found ought to be easy to avoid. Just for the record, OS X, Solaris 5.8, FreeBSD 4.8, and LinuxThreads support the UNIX98 version, so perhaps this isn't so important after all. Add Tru64 (aka OSF1, aka DEC Unix) to that list. Just checked it. Regards, Philip. ---(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] ECPG thread success (kind of) on Linux
BSD/OS supports: The pthreads library conforms to IEEE Std1003.1c (``POSIX''). How is that different from UNIX98? --- Philip Yarra wrote: On Fri, 27 Jun 2003 11:58 am, AgentM wrote: According to POSIX 1003.1c-1995, no such mutex-altering function exists. Thanks for the info - useful to know. lock the mutex- potentially again). Either that or the recursive locks can be eliminated. Avoiding recursive locks is my preference - the only two I have found ought to be easy to avoid. Just for the record, OS X, Solaris 5.8, FreeBSD 4.8, and LinuxThreads support the UNIX98 version, so perhaps this isn't so important after all. Add Tru64 (aka OSF1, aka DEC Unix) to that list. Just checked it. Regards, Philip. ---(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 -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Two weeks to feature freeze
See my recent commit of src/tools/pgtest. It might be a good start. --- Gavin Sherry wrote: On Thu, 26 Jun 2003, Kevin Brown wrote: The Hermit Hacker wrote: 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? Yes, I am (how hard can it be?, he asks himself, knowing all the while that it's a really bad idea to be asking that question. :-). But I haven't the faintest idea of how or where to even start, so pointers would be appreciated. Create/modify a script to automate some kind of download/sync, test and send failure results somewhere. Make it extensible, so that other tests can be easily added -- preferable in a self contained way. It should grow from there. Gavin ---(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 8: explain analyze is your friend
Re: [HACKERS] Two weeks to feature freeze
Rod Taylor [EMAIL PROTECTED] writes: I've not tried, but if PostgreSQL can do an 'out of tree' compile it could make it much easier. Yes it can, following the usual procedure for autoconfiscated trees: just invoke configure from an empty directory, eg mkdir build cd build ../pgsql/configure This is something that breaks regularly because few of the key developers use it :-(. If there were automatic tests that used that build setup, it would be a good thing 'cause it'd keep us honest. That said, poor cleanup would be a result of a broken make clean. Not to worry, the developers will notice that case fast enough. I think the auto test script should just rm -rf build and then proceed as above. 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
Good question. If it gets in 7.4, that would be more than a killer feature to put against 7.4 release, with due respect to all other enhancements in progress.. It's not going to happen. Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] Physical Database Configuration
Tablespaces databases schemas objects with each of them implemented as a directory and data files under it. If we could get a quota check propogated in both direction, that would be pretty good, may be a warning when things start getting close to limit. Database do not exist inside tablespaces, as they are not relations. Only tables, views, sequences and indexes will live in tablespaces. Even then, I probably won't bother allowing it for sequences and views since they don't occupy much space. A database can specify a DEFAULT tablespace, as can a schema, but they do not live in tablespaces themselves. Chris ---(end of broadcast)--- TIP 8: explain analyze is your friend
Tablespaces (was Re: [HACKERS] [GENERAL] Physical Database Configuration )
ROTFL... the answer is no. Feature freeze is Tuesday, people. In practice, the time to start coding new stuff is already long past. Especially major new stuff. If you start now you might have something done for 7.5. Can everyone who is interested in actually coding a tablespaces implementation please email me, and I will create a list and we'll get cracking. Maybe we'll have to run our own cvs or maybe the Postgres guys will be nice and do a branch for us :) So far, Shridhar and Gavin seem interested?? Chris ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Table partitioning question.
As people who are needing to move away from Oracle due to cost restrictions, I wanted to know how much work, or what the status is of this option. Please respond asap if possible. I have to give my VP info on this relatively soon. A lot of work is needed, and I wouldnt' even guarantee it being in 7.5... Chris ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] a problem with index and user define type
Tom Lane wrote: 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] yeah, you are right, it's out fault. We've mistakenly use PG_RETURN_INT16() to return from our am support function, which prune the sign information from the memcmp(), but we still declare the function to return INTEGER when CREATE FUNCTION. So the error, it's fixed now, and the datatype and index run smoothly. Thanks and Regards Laser ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Two weeks to feature freeze
On Thu, 26 Jun 2003, Bruce Momjian wrote: See my recent commit of src/tools/pgtest. It might be a good start. Yes this is a good start. This is a little concerning though: pg_ctl stop rm -rf $PGDATA Perhaps a warning is warranted (ie, $PGDATA shouldn't point to your production data cluster)? On another point, I have some ideas for Kevin and others interested in automated testing. Dann, Tom and others have voiced concern about the nature of testing itself: progammers testing for bugs they've solved; the difficulty/impossibility of testing for conditions you are unaware of, etc. ISTM that most of the bugs which aren't caught by the programmer, peer review and regresion test are revealed by users throwing data into a new version or a version different to that they are running in production and then running their existing code against it. That is, bugs are revealed by usage which developers did not foresee or did not think to test. So, if we had an automated testing framework which was extensible, postgres users could create testing scripts which simultate their application, with their application data (real or created specifically for the test). The win for users is that they can have their data/SQL tested on a variety of platforms, on new versions of postgres and the win for developers/testers is exposure of the code to unexpected usage. There will need to be checks and balances involved (select 1; is a pretty ordinary test), size limits/configurable thresholds for run times, and a repository of test results. Naturally, managing this could be quite time consuming if data formats change etc. but if people are keen... Gavin --- Gavin Sherry wrote: On Thu, 26 Jun 2003, Kevin Brown wrote: The Hermit Hacker wrote: 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? Yes, I am (how hard can it be?, he asks himself, knowing all the while that it's a really bad idea to be asking that question. :-). But I haven't the faintest idea of how or where to even start, so pointers would be appreciated. Create/modify a script to automate some kind of download/sync, test and send failure results somewhere. Make it extensible, so that other tests can be easily added -- preferable in a self contained way. It should grow from there. Gavin ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] row description for domain in 7.4
John DeSoi [EMAIL PROTECTED] writes: My vote would be to restore the previous behavior and add connection-specific setting for clients that need it. By my count you're in the minority --- there was no one lobbying for reporting domain OIDs in the previous threads, and at least two people strongly in favor of not doing so. While I don't have a strong opinion about it myself, I don't have the interest to make the behavior configurable, unless you can get some more votes for your position. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [INTERFACES] ECPG thread success (kind of) on Linux
On Fri, Jun 27, 2003 at 10:45:46AM +1000, Philip Yarra wrote: ECPGget_connection, both of which share a mutex. Would it be okay if we did the following: ... As you know I have never tried using threads, so feel free to go ahead and change this. Either commit to cvs ot send me a patch. 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 8: explain analyze is your friend
Re: [HACKERS] row description for domain in 7.4
On Thursday, June 26, 2003, at 11:22 PM, Tom Lane wrote: By my count you're in the minority --- there was no one lobbying for reporting domain OIDs in the previous threads, and at least two people strongly in favor of not doing so. While I don't have a strong opinion about it myself, I don't have the interest to make the behavior configurable, unless you can get some more votes for your position. If I understand the change correctly, won't this break existing clients that use the previous behavior (even if they don't use the 3.0 protocol)? Since few people are using 7.4, I don't expect I'll get any more votes unless things start breaking down the road (when it will be too late to change anything). No hard feelings about it, but I'm really surprised existing behavior will be broken when the technical reasons for changing it were so weak. Did I mis-analyze the situation in the previous email? Is it not just one query to the database to get the base type compared to a lot more effort to get the domain? Thanks, John DeSoi, Ph.D. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
