Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Am Donnerstag, 5. Dezember 2002 05:22 schrieb Lamar Owen: [cc: list trimmed] On Wednesday 04 December 2002 22:52, Philip Warner wrote: At 05:48 PM 4/12/2002 -0800, Christopher Kings-Lynne wrote: Lack of marketing is one of Postgres's major problems. What are the consequences of the problem? Actually, lack of easy upgrading is one of PostgreSQL's major problems But lack of focused marketing -- truthful, not, as has been said, like the 'Database HOWTO' -- is a real problem. It would be nice to increase our usage. If that is what we want, then fine. But I don't want to see any part of the development effort distorted or the existing user base inconvenienced in an effort to purely gain that market share. I usually associate increased marketing with decreased quality, and I think the causality works *both* ways. ISTM there's a separate, non-code-developer group doing this. It doesn't seem to take away _any_ developer resources to do an advocacy site. However, I seriously question the need in the long term for our sites to be as fractured as they are. Good grief! We've got advocacy.postgresql.org, techdocs.postgresql.org, odbc.postgresql.org, gborg.postgresql.org, developer.postgresql.org, jdbc.postgresql.org, etc. Oh, and we also have www.postgresql.org on the side? I think not. Oh, and they are fractured in their styles -- really, guys, we need a unified style here. Hi, there are lots of sites talking about postgresql. But if someone hear about postgresql he sure tries www.postgresql.org. There he just get a list of mirrors. Not really a good start. But worse: there is no links to gborg, advocacy, techdocs, ... Advocacy should be found at www.postgresql.org and have links to the other pages. I found gborg when reading the mailinglistst. It is something like a insidertip. www.apache.org has a much better structure. You go to www.apache.org and get a welcome-message and links to subprojects as the webserver. Another point that comes to my mind is design. I'm not a designer, but I like the design of www.postgresql.org but not advocacy.postrgresql.org. Tommi -- Dr. Eckhardt + Partner GmbH http://www.epgmbh.de ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Hi Tommi, Tommi Maekitalo wrote: snip Hi, there are lots of sites talking about postgresql. But if someone hear about postgresql he sure tries www.postgresql.org. There he just get a list of mirrors. Not really a good start. But worse: there is no links to gborg, advocacy, techdocs, ... Advocacy should be found at www.postgresql.org and have links to the other pages. I found gborg when reading the mailinglistst. It is something like a insidertip. There is a new front page for the www.postgresql.org site that was recently finished, and will be moved into the correct place soon. You can view it for now at wwwdevel.postgresql.org. The new front page has links to the other main websites, so it should help people find the information they need in a much easier way. :-) Hope that's helpful to know. :-) Regards and best wishes, Justin Clift snip Tommi -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: Porting from MySQL to PostgreSQL (was: [HACKERS] pgsql 7.2.3
Hi, On Mon, 2002-12-09 at 10:24, SEGUERRA FRANCIS TED ARANAS wrote: how do i port from mysql to postgresql?.. http://techdocs.postgresql.org/#convertfrom Best regards, . -- Devrim GUNDUZ TR.NET Sistem Destek Uzmani Tel : (312) 295 93 18 Fax : (312) 295 94 94 Tel : (216) 542 90 00 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] pgsql 7.2.3 crash
how do i port from mysql to postgresql?... thanks bruce, francis -- ov3rr|d3r ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Vince Vielhaber wrote: On Sun, 8 Dec 2002, Justin Clift wrote: Vince Vielhaber wrote: On Thu, 5 Dec 2002, Robert Treat wrote: Well, my previous employer uses postgresql, but they were under constant assault from their clients to use oracle or db2. Technically there was no reason to switch, but if your choice is switch databases or go out of business, there really isn't much choice. That tells me their clients wanted a commercial database, not one that's open source. All the marketing in the world won't change that. Really? Why do you say that? Because of this taken from the above quoted text: they were under constant assault from their clients to use oracle or db2 Last I looked neither Oracle or DB2 were open source, but they both just happen to be commercial and I don't see mysql mentioned. Anything else you don't understand about that? There are a number of reasons their clients could have been clamoring for DB2 or Oracle, only some of which are related to the fact that they're commercial, closed-source databases: 1. They already have significant in-house expertise with one or the other product. 2. They need 24x7 support, and are convinced that they'll get better support for Oracle or DB2 than anything else. 3. They want a company to blame in case things go wrong. 4. They require certain capabilities that they believe only DB2 or Oracle can provide. 5. They have an established partnership with IBM or Oracle. 6. Some combination of the above. Some of those reasons are such that it might be possible (depending on the specifics of the situation) to successfully market PostgreSQL (or even MySQL) to them, and some of them aren't. It just depends. And that's why it's a bad idea to simply discard that situation as one in which it would be impossible to market PostgreSQL. Marketing is the art of convincing someone that they want your product. Since the keyword here is want, it's an art that combines reason and emotion. Even if the situation seems logically hopeless (that is, there's no logical reason for the customer to prefer your product over another), you may still manage to successfully market your product to them by appealing to their emotions. Happens all the time. My personal feeling is that in the case of PostgreSQL, it should be marketed primarily using reason. More precisely, it should *not* be marketed to someone for whom a different product would better suit them. That, to me, would be shady at best and would eventually become a blemish on the reputation of the PostgreSQL community. But it doesn't mean giving up just because the client thinks he wants a commercial database: he may well want something else that a commercial database just happens to provide. If you're trying to sell someone on PostgreSQL, it behooves you to figure out what their real needs are first. Their actual needs may be significantly different from what they tell you they want. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On 9 Dec 2002 at 1:20, Kevin Brown wrote: 2. They need 24x7 support, and are convinced that they'll get better support for Oracle or DB2 than anything else. I have experienced what oracle support means for 24x7. I wouldn't even wish that penalty for my worst enemy. I can tell a story about it but I digress. Details aren't important though true. What really matters is how kindly and dearly you stand by your product. That is where all support originates.. Rest is marketing.. Bye Shridhar -- I have never understood the female capacity to avoid a direct answer toany question. -- Spock, This Side of Paradise, stardate 3417.3 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: Disabling triggers (was Re: [HACKERS] pgsql 7.2.3 crash)
Joe Conway wrote: The second case is usually something like an insert into the employee table fires off an email to IT to create a login and security to make a badge. Commonly we turn off workflows (by disabling their related triggers) in our development and test databases so someone doesn't disable the CEO's login when we fire him as part of our testing! I think in this scenario it is better to be able to disable the trigger globally ;-) I think in this scenario it's probably better to not fire the CEO, gratifying as it may be! :-) -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Sun, 8 Dec 2002, Josh Berkus wrote: But once Postgres has been packaged, we need to have a group making a loud enough noise to get the world to pay attention. I'm not asking everyone on this list to participate, but I am asking everyone on this list to recognize the utility of the effort. Here are my main problems with it. 1) They're marketing to those that are already sold on it. 2) They are, or at least were, insisting that I join their list to stay informed on what they're doing. 3) They need to learn HOW to market from someone who knows (not me) how or they'll never be taken seriously. That's all I'm going to say on this subject. Vince. -- Fast, inexpensive internet service 56k and beyond! http://www.pop4.net/ http://www.meanstreamradio.com http://www.unknown-artists.com Internet radio: It's not file sharing, it's just radio. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
On Mon, 09 Dec 2002 07:29:55 -0500, Vince Vielhaber wrote: On Sun, 8 Dec 2002, Josh Berkus wrote: But once Postgres has been packaged, we need to have a group making a loud enough noise to get the world to pay attention. I'm not asking everyone on this list to participate, but I am asking everyone on this list to recognize the utility of the effort. Here are my main problems with it. 1) They're marketing to those that are already sold on it. I think we've already shown why it doesn't hurt to market to the converted. I'll add that if you compare the 7.2 press release with the 7.3 press release, you'll see none of the technical content was removed. 2) They are, or at least were, insisting that I join their list to stay informed on what they're doing. I think it was only suggested that you join since you obviously have a lot of feedback you'd like to give to the group. Since a lot of people on -hackers don't want to be involved in the process, it seemed a bad idea to post all of the detail work to this list. 3) They need to learn HOW to market from someone who knows (not me) how or they'll never be taken seriously. I've seen more posts saying that until you get a decent website your not going to be taken seriously than anything else, by far. While I'm hoping that's not entirely true, I do agree that until we get a coordinated and open web development process the advocacy group is going to have a much harder go of it. Robert Treat ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] DBD::Pg module on Windows
Does anybody know where I can find a newer DBD::Pg module for Windows NT? The only pre-compiled one I can find is 0.98, which is based on a PostgreSQL 7.0 library set. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Vince Vielhaber [EMAIL PROTECTED] writes: 1) They're marketing to those that are already sold on it. I think the upshot of the prior discussion was that the outside press release shouldn't have been used as the release announcement for the existing mailing lists. Fine, they made a one-time mistake. 2) They are, or at least were, insisting that I join their list to stay informed on what they're doing. It seems to me that people have made it perfectly clear that they don't want to hear about marketing on the -hackers or -general lists. Taking it to a marketing-specific list seems like exactly the right response. Where do you think it should be discussed? regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] Let's create a release team
Dan Langille [EMAIL PROTECTED] writes: Let's create a release team. This strategy is one well established in other projects and in industry. For lack of a better starting reference, let me suggest http://www.freebsd.org/releng/charter.html as a starting point for consideration. See also http://www.freebsd.org/releng/index.html. This will also lighten the load on the core team allowing them to focus on development and such. I don't really see any value-added here. The core committee's only routinely-exercised function is to organize releases; separating that out would leave core with nothing to do. Also, to the extent that core has any real or perceived authority in the project, I think it comes from having control of the release process --- there's surely no other reason for people to defer to the core team as a group (as opposed to whatever respect might be accorded to individual people as a result of their individual contributions). So ISTM such a reorganization would leave the core committee as a figurehead and make the release team into the effective new core. 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: Porting from MySQL to PostgreSQL (was: [HACKERS] pgsql 7.2.3
thanks On 9 Dec 2002, Devrim GUNDUZ wrote: Hi, On Mon, 2002-12-09 at 10:24, SEGUERRA FRANCIS TED ARANAS wrote: how do i port from mysql to postgresql?.. http://techdocs.postgresql.org/#convertfrom Best regards, . -- ov3rr|d3r ---(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] proposal: array utility functions phase 1
Joe Conway [EMAIL PROTECTED] writes: Yes, this is exactly what I was yearning to do. Was there a spec or technical reason (or both) for not allowing the following? select * from array_values(g.grolist), pg_group g where g.groname = 'g2'; This seems fairly unworkable to me as-is. By definition, WHERE selects from a cross-product of the FROM tables; to make the above do what you want, you'd have to break that fundamental semantics. The semantics of explicit JOIN cases would be broken too. What we need is some kind of explicit multi-level SELECT operation. Perhaps it would help to think about the analogy of aggregates of aggregate functions, which are impossible to express properly in a single SELECT but work nicely given subselect-in-FROM. Subselect-in-FROM doesn't seem to get this job done though. Right offhand I don't see any reasonable syntax other than function-in-the-SELECT-list, which shoots us right back into the messinesses of the Berkeley implementation. However, we do now have the precedent of the table-function AS clause. Does it help any to do something like SELECT grosysid, array_values(grolist) AS (array_index,member_id) FROM pg_group where groname = 'g2'; (Again you could wrap this in an outer SELECT to transform the member_ids to member_names.) The real problem with the Berkeley approach shows up when you consider what happens with multiple table functions called in a single SELECT. The code we currently have produces the cross-product of the implied rows (or at least it tries to, I seem to recall that it doesn't necessarily get it right). That's pretty unpleasant, and though you can filter the rows in an outer SELECT, there's no way to optimize the implementation into a smarter-than-nested-loop join. It seems like somehow we need a level of FROM/WHERE producing some base rows, and then a set of table function calls to apply to each of the base rows, and then another level of WHERE to filter the results of the function calls (in particular to provide join conditions to identify which rows to match up in the function outputs). I don't see any way to do this without inventing new SELECT clauses out of whole cloth ... unless SQL99's WITH clause helps, but I don't think it does ... How ugly/difficult would it be to allow the planner to interrogate the function and let the function report back a tupledesc based on the actual runtime input parameters? Parse-time, not run-time. It could be done --- IIRC, the auxiliary function info call we introduced in the V1 fmgr protocol was deliberately designed to allow expansion in this sort of direction. But it would have to take a tupledesc (or some similar static description) and return another one. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Vince, Here are my main problems with it. 1) They're marketing to those that are already sold on it. First off ... not they, you. I'm a member of Advocacy; so are Robert, Justin, Neil, Marc, Bruce and several other members of this list. The advocacy group is not some privately sponsored bunch of marketeers; *we* are your fellow contributors. Yes, we should have released a different version of the announcement to the internal lists. I believe that I have already explained how that happened. 2) They are, or at least were, insisting that I join their list to stay informed on what they're doing. Unless you don't want to stay informed. In which case, you're welcome not to, and one or more Advocacy people will join wwwdevel to keep links synchronized. Nobody's going to make you do anything. This is Open Source. 3) They need to learn HOW to market from someone who knows (not me) how or they'll never be taken seriously. One of our volunteers is a professional PR person. Two are periodical writers. I started (with 2 partners) the OpenOffice.org Marketing Project, which was cited by one columnist (Amy Wohl) as a better volunteer marketing team than Sun could put together for a million-dollar budget (paraphrased). 3 of us are small business owners. I think we have as much or more combined experience as the marketing department of any start-up, without the baggage. Also, half a marketing effort is better than none. At the very least, we need to keep Postgres in the press, else we are likely to see PostgreSQL fade into permanent obscurity. The technology world is full of technically good but poorly marketed products -- FoxPro anyone? Paradox? Beta video? Amiga? Last week I got a 5-page long database developer survey from EvansData. It mentioned 10 other database platforms -- including Ingres! -- but not PostgreSQL. I personally don't want to see that again. Sure, we got off to a rocky start. However, I will point out that our first release happened to fall on a major American holiday; this made it extra hard to organize the effort, and things didn't work out well. But the answer to that is not to abandon the effort, but to plan and prepare better in the future. I would also be grateful if us folks on the Advocacy team could look to Hackers to make sure that we *aren't* going off on a tangent, or pushing Postgres in a way that's inconsistent with the development goals for the database. We *want* Advocacy to be an integral part of the Postgres community, serving the general goal of making Postgres the best possible ORDBMS in existence. -Josh Berkus ---(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: [PATCHES] [HACKERS] Patch to make Turks happy.
Peter, is that patch OK for 7.3.1? I am not sure. --- Peter Eisentraut wrote: Bruce Momjian writes: I am not going to apply this patch because I think it will mess up the handling of other locales. This patch looks OK to me. Normally, character set names should use identifier case-folding rules anyway, so seems to be a step in the right direction. Much better than saying that users of certain locales can't properly use PostgreSQL. --- Nicolai Tufar wrote: Hi, Yet another problem with Turkish encoding. clean_encoding_name() in src/backend/utils/mb/encnames.c uses tolower() to convert locale names to lower-case. This causes errors if locale name contains capital I and current olcale is Turkish. Some examples: aaa=# \l List of databases Name| Owner | Encoding ---+---+-- aaa | pgsql | LATIN5 bbb | pgsql | LATIN5 template0 | pgsql | LATIN5 template1 | pgsql | LATIN5 (4 rows) aaa=# CREATE DATABASE ccc ENCODING='LATIN5'; ERROR: LATIN5 is not a valid encoding name aaa=# \encoding SQL_ASCII aaa=# \encoding SQL_ASCII SQL_ASCII: invalid encoding name or conversion procedure not found aaa=# \encoding LATIN5 LATIN5: invalid encoding name or conversion procedure not found Patch, is a simple change to use ASCII-only lower-case conversion instead of locale-dependent tolower() Best regards, Nic. *** ./src/backend/utils/mb/encnames.c.origMon Dec 2 15:58:49 2002 --- ./src/backend/utils/mb/encnames.c Mon Dec 2 18:13:23 2002 *** *** 407,413 for (p = key, np = newkey; *p != '\0'; p++) { if (isalnum((unsigned char) *p)) ! *np++ = tolower((unsigned char) *p); } *np = '\0'; return newkey; --- 407,416 for (p = key, np = newkey; *p != '\0'; p++) { if (isalnum((unsigned char) *p)) ! if (*p = 'A' *p = 'Z') ! *np++ = *p + 'a' - 'A'; ! else ! *np++ = *p; } *np = '\0'; return newkey; ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] Patch to make Turks happy.
Bruce Momjian writes: Peter, is that patch OK for 7.3.1? I am not sure. Definitely. It's a bug fix. -- Peter Eisentraut [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] PostgreSQL Global Development Group
Robert Treat writes: I think we've already shown why it doesn't hurt to market to the converted. I'll add that if you compare the 7.2 press release with the 7.3 press release, you'll see none of the technical content was removed. Compare the 7.3 release notes, written for the most part by Bruce Momjian and revised by a couple of other developers, to the press release, written by people who were obviously ill-informed. Release notes: Schemas Schemas allow users to create objects in their own namespace so two people or applications can have tables with the same name. There is also a public schema for shared tables. Table/index creation can be restricted by removing permissions on the public schema. Press release: Schemas PostgreSQL now joins the handful of ORDBMS's to support the SQL 92 Schema specification, improving both enterprise database management and security through the use of namespaces. This not only removes all information about the actual use of schemas, it contains completely bogus information, because SQL 92 is obsolete, there is no SQL Schema specification, and none of this has to do with being an ORDBMS. And besides, whose hands were used to do the counting? Release notes: Drop Column PostgreSQL now supports the ALTER TABLE ... DROP COLUMN functionality. Press release: void Release notes: Table Functions Functions returning multiple rows and/or multiple columns are now much easier to use than before. You can call such a table function in the SELECT FROM clause, treating its output like a table. Also, PL/pgSQL functions can now return sets. Press release: Table Functions PostgreSQL version 7.3 has greatly simplified returning result sets of rows and columns in database functions. This significantly enhances the useability of stored procedures in PostgreSQL, and will make it even easier to port Oracle applications to PostgreSQL. Again, this removes all details about how the feature can be used, and again it inserts completely bogus information. There are no sets of columns, and PostgreSQL does not have stored procedures. Also, it makes it look as though PostgreSQL exists merely to reimplement Oracle. Release notes: Prepared Queries PostgreSQL now supports prepared queries, for improved performance. Press release: - Prepared queries for maximized performance on common requests. I'm curious to know how the marketing department determined that this is, in fact, the maximal performance. Release notes: Dependency Tracking PostgreSQL now records object dependencies, which allows improvements in many areas. DROP statements now take either CASCADE or RESTRICT to control whether dependent objects are also dropped. Press release: - Enhanced dependency tracking for complex databases. Again, all relevant information dropped, replaced by marketing fluff. Release notes: Privileges Functions and procedural languages now have privileges, and functions can be defined to run with the privileges of their creator. Press release: Security Advances In response to community demands, PostgreSQL has added schema, function, and other permissions and settings to increase the database administrator's granular control over security. Information dropped, replaced by broad and repetitive verbiage. But at least they didn't write, in response to market pressures. And my personal favorite is this: Release notes: Internationalization Both multibyte and locale support are now always enabled. Press release: - Supports data in many international characters sets (UNICODE, EUC_JP, EUC_CN, EUC_KR, JOHAB, EUC_TW, ISO 8859-1 ECMA-94, KOI8, WIN1256, etc...) That is just plain wrong. Support for various character sets is years old. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DB Tuning Notes for comment...
On Sun, 2002-12-08 at 09:41, Philip Warner wrote: Any comments or suggestions would be welcome. first and foremost, this is really excellent work! We need to look into getting this info into the standard documentation and/or Bruce's tuning guide. Tuning == 1. max_fsm_relations First of all, the free space manager is useless at managing free space if it can not map all relations (including system relations and toast relations). The following query should give the correct ballpark: select count(*) from pg_class where not relkind in ('i','v'); It should be noted that if you have multiple databases, you'll need to get the number of relations minus the system tables for each database, then add in the number of system tables. Set max_fsm_relations to a number greater than this. Add extra to deal with any tables you will create etc. It costs 40 bytes per table, so be generous - if it is set too low, you will get bizarre space usage. 2. VACUUM Frequency --- Ideally VACUUM should run constantly; a future version will support something like it. But for now, vacuum should be run when a significant amount of data has been inserted, updated or deleted. The definition of 'significant' is not immediately obvious. I don't think this is entirely true. On tables that have large numbers of inserts, but no updates or deletes, you do not need to run vacuum. It might be helpful to run analyze on these tables if your inserting enough data to change the statistical relationships, but vacuum itself is not needed. Most tables will *not* be updated frequently in most databases; such tables can be vacuumed irregularly, or vacuumed when the more frequently updated tables are vacuumed. In our specific case we have one table that has a few rows ( 1000), but it is updated as many as 3 times per second. In this case, we chose a 5 minute interval, which results in at worst 1000 'dead' rows in the table as a result of the updates. Since it was such a small table, we saw no reason to vacuum every minute, or even constantly. I have some similar tables in my system, with between 250 and 3500 rows. These tables turn over at least every 15 minutes, so I have decided on a 10 minute vacuum interval. As with Phillip's, since they are small tables, more frequent vacuuming seemed excessive. For larger or more complex tables, the output of VACUUM ANALYZE must be used. snip again, great work Philip. Robert Treat ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DB Tuning Notes for comment...
Robert Treat wrote: On Sun, 2002-12-08 at 09:41, Philip Warner wrote: Any comments or suggestions would be welcome. first and foremost, this is really excellent work! We need to look into getting this info into the standard documentation and/or Bruce's tuning guide. Seconded! Tuning == 1. max_fsm_relations First of all, the free space manager is useless at managing free space if it can not map all relations (including system relations and toast relations). The following query should give the correct ballpark: select count(*) from pg_class where not relkind in ('i','v'); It should be noted that if you have multiple databases, you'll need to get the number of relations minus the system tables for each database, then add in the number of system tables. Set max_fsm_relations to a number greater than this. Add extra to deal with any tables you will create etc. It costs 40 bytes per table, so be generous - if it is set too low, you will get bizarre space usage. 2. VACUUM Frequency --- Ideally VACUUM should run constantly; a future version will support something like it. But for now, vacuum should be run when a significant amount of data has been inserted, updated or deleted. The definition of 'significant' is not immediately obvious. I don't think this is entirely true. On tables that have large numbers of inserts, but no updates or deletes, you do not need to run vacuum. It might be helpful to run analyze on these tables if your inserting enough data to change the statistical relationships, but vacuum itself is not needed. In my experience I've seen tables with numerous indexes continue to benefit greatly from vacuum/vacuum full operations when large volumes of inserts are performed. This is true even when the update/delete activity on the base table itself is manageable. While dropping and recreating the index after loading is possible in some cases, my general comment is that index maintenance is an issue you should keep in mind when designing your vacuum strategy. Most tables will *not* be updated frequently in most databases; such tables can be vacuumed irregularly, or vacuumed when the more frequently updated tables are vacuumed. In our specific case we have one table that has a few rows ( 1000), but it is updated as many as 3 times per second. In this case, we chose a 5 minute interval, which results in at worst 1000 'dead' rows in the table as a result of the updates. Since it was such a small table, we saw no reason to vacuum every minute, or even constantly. I have some similar tables in my system, with between 250 and 3500 rows. These tables turn over at least every 15 minutes, so I have decided on a 10 minute vacuum interval. As with Phillip's, since they are small tables, more frequent vacuuming seemed excessive. For larger or more complex tables, the output of VACUUM ANALYZE must be used. snip again, great work Philip. Robert Treat ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html ss Scott Shattuck Technical Pursuit Inc. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] Sequence Cleanup
Below is a short list of TODOs on sequences I wish to tackle over the next week. CREATE SEQUENCE: - Addition of NO MAXVALUE and NO MINVALUE options, which use the system implementation settings -- for SQL2002 compliance, and makes ALTER SEQUENCE slightly easier. ALTER SEQUENCE: - Supports RESTART WITH, + options from Create Statement (including NO MAXVALUE, NO MINVALUE). Modify init_params to deal with seq-options only. This allows AlterSequence to use it as well. Ok, this is where it gets confusing. Right now setval() is implemented in such a manner that it cannot be rolled back (see SETVAL NOTE below), but I'd like ALTER SEQUENCE to be transaction safe. Can I assume that a standard simple_heap_update() is valid against the sequence, so long as I set xmin = FrozenTransactionId and create 2 XLog records similarly to DefineSequence? Now, do I need to do anything to clear the cache of other backends, or simply let them play themselves out. I'm leaning towards the latter, as nextval() appears to read in the min / max value from the sequence buffer. A transaction safe alter sequence, implemented in the standard method, will result in two tuples. Doing this many times could make sequences quite slow. It looks like read_info() depends on a single value value in the sequence table. Do I need to do something more complex like a relfileswap, generating a fresh tuple for it -- all parts of DefineSequence() except the DefineRelation() step? Anyway, I'll fiddle with the above two approaches, but would appreciate input where appropriate. -- SETVAL NOTE -- a=# select nextval('test'); nextval - 2 (1 row) a=# begin; BEGIN a=# select setval('test', 50); setval 50 (1 row) a=# select nextval('test'); nextval - 51 (1 row) a=# rollback; ROLLBACK a=# select nextval('test'); nextval - 52 (1 row) -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] DB Tuning Notes for comment...
Robert Treat [EMAIL PROTECTED] writes: On Sun, 2002-12-08 at 09:41, Philip Warner wrote: First of all, the free space manager is useless at managing free space if it can not map all relations (including system relations and toast relations). The following query should give the correct ballpark: select count(*) from pg_class where not relkind in ('i','v'); FSM entries aren't needed for sequences either, so more correct is select count(*) from pg_class where relkind in ('r', 't'); It should be noted that if you have multiple databases, you'll need to get the number of relations minus the system tables for each database, then add in the number of system tables. You're assuming that system tables are shared, which they mostly aren't. Summing the pg_class count over all databases (or all that get vacuumed, anyway; you can exclude template0) will be close enough. BTW, this neglects what seems possibly an important factor: you don't need FSM entries for tables that are effectively read-only or insert-only (no deletes or updates). At least in some database designs, that's a significant number of tables. However, I suspect that the present FSM code is not very effective at deciding *which* tables to track if it has too few slots, so Philip's advice of make sure there's one for every table may be the best in the near term. But we need to work at improving that logic. I have some uncommitted patches concerning the FSM management heuristics from Stephen Marshall, which I deemed too late/risky for 7.3, but we should get something done for 7.4. Anyone interested in playing around in this area? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DB Tuning Notes for comment...
Scott Shattuck [EMAIL PROTECTED] writes: Robert Treat wrote: I don't think this is entirely true. On tables that have large numbers of inserts, but no updates or deletes, you do not need to run vacuum. In my experience I've seen tables with numerous indexes continue to benefit greatly from vacuum/vacuum full operations when large volumes of inserts are performed. This is true even when the update/delete activity on the base table itself is manageable. This is hard to believe, as VACUUM does not even touch the indexes unless it has found deletable tuples --- and I am quite certain that btree indexes, at least, do not do any VACUUM-time reorganization beyond deleting deletable entries. (I wouldn't swear to it one way or the other for GiST though.) Robert's opinion coincides with what I know of the code. 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] Sequence Cleanup
Rod Taylor [EMAIL PROTECTED] writes: I'd like ALTER SEQUENCE to be transaction safe. I think that's inherently impossible without breaking the existing behavior of setval/nextval, which is something we will not accept. ALTER SEQUENCE would be better thought of as a form of setval with even more parameters, but not fundamentally different semantics. Can I assume that a standard simple_heap_update() is valid against the sequence, You can be certain that it is not. There can be only one tuple in a sequence table. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Yahoo hosting service using MySQL
http://webhosting.yahoo.com/ps/wh/prod/p3.html MySQL® is considered the most popular open source database in the world. Fast and powerful, it is perfect for high-traffic, heavy-load sites. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DB Tuning Notes for comment...
Tom Lane wrote: Scott Shattuck [EMAIL PROTECTED] writes: Robert Treat wrote: I don't think this is entirely true. On tables that have large numbers of inserts, but no updates or deletes, you do not need to run vacuum. In my experience I've seen tables with numerous indexes continue to benefit greatly from vacuum/vacuum full operations when large volumes of inserts are performed. This is true even when the update/delete activity on the base table itself is manageable. This is hard to believe, as VACUUM does not even touch the indexes unless it has found deletable tuples --- and I am quite certain that btree indexes, at least, do not do any VACUUM-time reorganization beyond deleting deletable entries. (I wouldn't swear to it one way or the other for GiST though.) Robert's opinion coincides with what I know of the code. Willing to learn here but skipping a vacuum full has caused some issues for us. Here's some data from a recent 3 day test run that was done with regular vacuums but not vacuum fulls. When running with vacuum full the indexes remain in line: nsuite-10=# select relname, relpages, reltuples from pg_class where relname not like 'pg_%' order by reltuples desc; -[ RECORD 1 ]-- relname | directory_fullpath_ix relpages | 96012 reltuples | 1.38114e+06 -[ RECORD 2 ]-- relname | directory_pkey relpages | 16618 reltuples | 1.38114e+06 -[ RECORD 3 ]-- relname | directory relpages | 23924 reltuples | 59578 snip Needless to say, the system performance was pathetic but the test did serve to highlight this index issue. Anyone want to give a quick summary of index maintenance or give me a pointer into the codebase where someone who's not a C expert might still get a sense of what's being done? I'd really like to understand how an index can get so completely out of whack after a weekend of testing. It seems you're telling me that the data here proves there's an update or delete going on somewhere in the system, even though this test is of a database initialization driven by a stored procedure with no update or delete operations targeting the directory table. There may be some operations being done external to that process that I've not been made aware of but I'm still curious to learn more about indexing behavior so I know why something like this happens in the first place. ss ---(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: [PATCHES] [HACKERS] Patch to make Turks happy.
Thanks. Applied for 7.3.1. --- Peter Eisentraut wrote: Bruce Momjian writes: Peter, is that patch OK for 7.3.1? I am not sure. Definitely. It's a bug fix. -- Peter Eisentraut [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]) -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] IPv6 patch rejected
I didn't read my email this weekend, so I am sorry to be late getting back to you on this. First, let me say I am excited about this patch. Several people have asked for IPv6 support, but you are the first person to actually submit a patch for it. I want to comment on the patch a bit because IPv6 is usually a difficult feature to add, considering the many platforms we support. First, I am running BSD/OS, so I have the bind 8.2.3 Inet routines in my libc. However, I do not have IPv6 enabled in my kernel. Your patch will have to deal with such systems, _and_ platforms that don't support IPv6 at all. It appears the patch does a few things: changes comparison of port-raddr.sa.sa_family == AF_INET to call to a new function isAF_INETx changes inet_aton() call to a new function SockAddr_pton() extensively modifies StreamServerPort adds modifies StreamServerPortSubAFUNIX1/2 modifies connectDBStart To better integrate your patch, I have: reformatted to fit our coding style renamed file v6utils.c to ipv6.c removed 'configure' link code to use Makefile link like md5.c added code to create IPv4 port if IPv6 port creation fails I need to continue reviewing the code and add a configure test to determine if IPv6 can compile on the machine. The fallback to IPv4 should be fine on machines that don't have IPv6 in their kernels. The current patch can be downloaded from: ftp://candle.pha.pa.us/pub/postgresql/mypatches/ipv6 --- Nigel Kukard wrote: Hrmmm, Is the compiling or running of postgresql a problem? if its the compiling we could add #ifdef's maybe to check if we have INET6 support... or even add it to the configure.in, if its running of postgresql which is the problem i have no clue how to get around that. thoughts? On Fri, 6 Dec 2002, Bruce Momjian wrote: I now have the INETv6 patch working using IPv4 on my machine, and I don't have IPv6 enabled in my kernel. Tomorrow, I will review the entire patch for portability issues, then post it so others can test it. I am pretty sure it is going to fail if your machine isn't INET6 aware, which may be many. --- The INETv6 patch was rejected because of this report, and an error on postmaster startup from BSD/OS: LOG: FATAL: StreamServerPort: getaddrinfo2() failed: hostname nor servname provided, or not known Please submit a new patch that addresses these issues. I can work with you to do testing. --- Joe Conway wrote: Bruce Momjian wrote: Fixing now. This just isn't my night --- another patch with a missing file. OK - I can run configure and make now, but I'm getting these warnings: In file included from ../../../../src/include/libpq/libpq.h:22, from printtup.c:20: ../../../../src/include/libpq/v6util.h:3: warning: `struct addrinfo' declared inside parameter list ../../../../src/include/libpq/v6util.h:3: warning: its scope is only this definition or declaration, which is probably not what you want. ../../../../src/include/libpq/v6util.h:5: warning: `struct addrinfo' declared inside parameter list lots of similar warnings to the above -- and: auth.c: In function `ClientAuthentication': auth.c:414: warning: passing arg 1 of `isAF_INETx' from incompatible pointer type gcc -O2 -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -c -o crypt.o crypt.c -MMD In file included from ../../../src/include/libpq/libpq.h:22, from crypt.c:24: Joe ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- Nigel Kukard (Chief Executive Officer) Lando Technologies Africa (Pty) Ltd [EMAIL PROTECTED] www.lando.co.za Tel: 083 399 5822 Fax: 086 1100036 Hoheisen Park Bellville, Cape Town National Internet Service Provider The best language to use is the language that was designed for what you want to use it for - 1997 = Disclaimer -- The contents of this message and any attachments are intended solely for the addressee's use and may be legally privileged and/or confidential information. This message may not be retained, distributed, copied or used if you are not he addressee of this message. If this message was sent to you in error, please
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Fri, 6 Dec 2002, Thomas O'Connell wrote: I was surprised, for instance, to receive a non-list email announcing the release of the software but then to have to wait for days actually to see it show up on the official (or even the advocacy) website in a news item. Even now it is not listed at PostgreSQL, Inc. ack, an oversight, I can assure you ... I have proded the apporpriate ppl for this one :( ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] DB Tuning Notes for comment...
Scott Shattuck [EMAIL PROTECTED] writes: Willing to learn here but skipping a vacuum full has caused some issues for us. Here's some data from a recent 3 day test run that was done with regular vacuums but not vacuum fulls. When running with vacuum full the indexes remain in line: nsuite-10=# select relname, relpages, reltuples from pg_class where relname not like 'pg_%' order by reltuples desc; -[ RECORD 1 ]-- relname | directory_fullpath_ix relpages | 96012 reltuples | 1.38114e+06 -[ RECORD 2 ]-- relname | directory_pkey relpages | 16618 reltuples | 1.38114e+06 -[ RECORD 3 ]-- relname | directory relpages | 23924 reltuples | 59578 snip blink There's no way that the index and table tuple counts should get that far out of line; in the absence of any concurrent updates, they should be *equal* (or index table, if you have a partial index, which I assume these are not). I would credit the recorded index count exceeding the recorded table count by the number of tuples inserted/ updated while a (plain) VACUUM is in process on that table --- but this doesn't look like it meets that situation. There was a bug a long time ago wherein vacuum would forget to update pg_class.reltuples for indexes in some cases, but according to the CVS logs that was fixed before 7.2 release. What version are you running exactly? In any case, you seem to be dealing with some kind of bug here. It might be helpful to look at the output of vacuum verbose directory if you still have it available. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] SIGSEGV
Using cvs source of Dec 4 15:13: test=# \d amount Table public.amount Column | Type | Modifiers +-+ id | integer | not null default nextval('public.amount_id_seq'::text) value | integer | test=# select value from amount; value --- (0 rows) test=# select value from amount; server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. The connection to the server was lost. Attempting reset: Failed. !# Not very graceful... (and this is different to the geqo prob I saw with my libpq++ program, cured with geqo=false (Thanks Tom!)) Program received signal SIGSEGV, Segmentation fault. transformTargetEntry (pstate=0x82e235c, node=0x82e21fc, expr=0x0, colname=0x0, resjunk=0 '\000') at parse_target.c:61 61 if (IsA(expr, RangeVar)) (gdb) bt #0 transformTargetEntry (pstate=0x82e235c, node=0x82e21fc, expr=0x0, colname=0x0, resjunk=0 '\000') at parse_target.c:61 #1 0x80c2af0 in transformTargetList (pstate=0x82e235c, targetlist=0x82e2234) at parse_target.c:192 #2 0x80a9c00 in transformSelectStmt (pstate=0x82e235c, stmt=0x82e22b4) at analyze.c:1654 #3 0x80a7feb in transformStmt (pstate=0x82e235c, parseTree=0x82e22b4, extras_before=0xbfbfa9b0, extras_after=0xbfbfa9b4) at analyze.c:308 #4 0x80a7bd0 in parse_analyze (parseTree=0x82e22b4, parentParseState=0x0) at analyze.c:147 #5 0x813e1c0 in pg_analyze_and_rewrite (parsetree=0x82e22b4) at postgres.c:408 #6 0x813e4a3 in pg_exec_query_string (query_string=0x82e201c, dest=Remote, parse_context=0x828c8ac) at postgres.c:696 #7 0x813f935 in PostgresMain (argc=5, argv=0xbfbfaca8, username=0x826a925 prlw1) at postgres.c:2016 #8 0x8124332 in DoBackend (port=0x826a800) at postmaster.c:2293 #9 0x8123c25 in BackendStartup (port=0x826a800) at postmaster.c:1915 #10 0x8122e0b in ServerLoop () at postmaster.c:1002 #11 0x8122972 in PostmasterMain (argc=3, argv=0x8266030) at postmaster.c:781 #12 0x80fb135 in main (argc=3, argv=0xbfbfb4b4) at main.c:209 #13 0x8069e84 in ___start () Cheers, Patrick ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DB Tuning Notes for comment...
At 03:54 PM 9/12/2002 -0500, Tom Lane wrote: However, I suspect that the present FSM code is not very effective at deciding *which* tables to track if it has too few slots, You are definitely right there. I think it would be worth looking at removing max_fsm_tables as a tuning option, and adding a 'relhasfsm' flag to pg_class for those tables that should not be mapped. Default to 't'. Then, make the table grow dynamically as tables are added, or when a VACUUM occurs... AFAICT, the only justification for a smaller list of relations is for those that are *almost never* subject to deletes or updates. They are certainly common in DB design, but I'd let the DBA designate them. Does this sound reasonable? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DB Tuning Notes for comment...
At 02:46 PM 9/12/2002 -0500, Robert Treat wrote: getting this info into the standard documentation and/or Bruce's tuning guide. I'd vote for the standard docs since it is sufficiently basic as to be needed by most users. We either need a tuning chapter or a new section in runtime configuration. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] DB Tuning Notes for comment...
Philip Warner [EMAIL PROTECTED] writes: I think it would be worth looking at removing max_fsm_tables as a tuning option, and adding a 'relhasfsm' flag to pg_class for those tables that should not be mapped. Default to 't'. Then, make the table grow dynamically as tables are added, or when a VACUUM occurs... If we could make the table grow dynamically then there'd not be much need for the config parameters at all. The real problem is to fit into a shmem segment whose size has to be frozen at postmaster start (which, not incidentally, is before we've ever looked at the database...). We could make the constraint be on total space for relation entries + page entries rather than either individually, but I think that'd mostly make it harder to interpret the config setting rather than offer any real ease of administration. AFAICT, the only justification for a smaller list of relations is for those that are *almost never* subject to deletes or updates. They are certainly common in DB design, but I'd let the DBA designate them. It doesn't seem to me to be that hard for the system to recognize them automatically. Basically, if there are no holes of useful size in the table, there's no need to create an FSM entry for it. The trick is useful size here --- but VACUUM already does the work needed to estimate an average tuple size, so I'd think it could do a reasonably good job of realizing that all the available holes are just leftover space. (The relation's very last page is also a special case that's likely not special-cased correctly at the moment: perhaps it should never be entered in FSM at all, certainly not if it's the only page that would be entered.) regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] SIGSEGV
Patrick Welche [EMAIL PROTECTED] writes: test=# select value from amount; server closed the connection unexpectedly This is a known bug also (in the domain-constraint patch, which has turned VALUE into a reserved word, a rather unpleasant price to pay for the feature IMHO). Rod claimed his latest patch fixes it, but AFAIK that hasn't been applied yet. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] SIGSEGV
On Mon, 2002-12-09 at 19:04, Tom Lane wrote: Patrick Welche [EMAIL PROTECTED] writes: test=# select value from amount; server closed the connection unexpectedly This is a known bug also (in the domain-constraint patch, which has turned VALUE into a reserved word, a rather unpleasant price to pay for the feature IMHO). Rod claimed his latest patch fixes it, but AFAIK that hasn't been applied yet. It was applied a couple of days ago by Bruce. a=# select value; ERROR: VALUE is not allowed in expression for node 732 Error message isn't great, but it doesn't crash anymore. -- Rod Taylor [EMAIL PROTECTED] PGP Key: http://www.rbt.ca/rbtpub.asc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] DB Tuning Notes for comment...
At 03:54 PM 9/12/2002 -0500, Tom Lane wrote: FSM entries aren't needed for sequences either, so more correct is select count(*) from pg_class where relkind in ('r', 't'); presumably: select count(*) from pg_class where relkind in ('r', 't', 'i'); Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] PostgreSQL Global Development Group
On Monday 09 December 2002 12:50, Peter Eisentraut wrote: Compare the 7.3 release notes, written for the most part by Bruce Momjian and revised by a couple of other developers, to the press release, written by people who were obviously ill-informed. If people want to see the details, let them read the release-notes themselves, and let it be the detail document. A press release of the detail that the release notes have will not get any 'press' -- and I say that wearing my radio broadcaster hat, where I have personally approved or disapproved 'press releases' in news stories in the past. Getting 'press' is what a 'press release' is all about. So, IMHO, the pgsql-announce mailing list should get the press release along with the other 'outside' press outlets -- and the developers' lists (since hackers is far from the only one) should, IMHO again, get a copy of the release notes. And my personal favorite is this: Release notes: Internationalization Both multibyte and locale support are now always enabled. Press release: - Supports data in many international characters sets (UNICODE, EUC_JP, EUC_CN, EUC_KR, JOHAB, EUC_TW, ISO 8859-1 ECMA-94, KOI8, WIN1256, etc...) That is just plain wrong. Support for various character sets is years old. It IS true that the current release supports all of these. The blanket 'Supports' statement above quoted was not true in the blanket case until the 'support' became default, since there were cases that this would not be true. Support != 'if you pass the right parameters to configure this will work', at least not at the press release level. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Peter Eisentraut [EMAIL PROTECTED] writes: Robert Treat writes: I think we've already shown why it doesn't hurt to market to the converted. I'll add that if you compare the 7.2 press release with the 7.3 press release, you'll see none of the technical content was removed. Compare the 7.3 release notes, written for the most part by Bruce Momjian and revised by a couple of other developers, to the press release, written by people who were obviously ill-informed. snip for brevity So does this mean that you are volunteering to proofread the next marketing announcement? I would wager that only a PostgreSQL developer (such as yourself) could have picked out the inconsistencies that you were able to find. The press release might have seemed obviously ill-informed to you, but it seemed just fine to me, and I can guarantee you that I am at least an order of magnitude more informed about PostgreSQL than the average manager. The difference between the press release and the Release Notes is the intended audience. The folks that the press release is aimed at probably don't have any idea that SQL 92 is obsolete, or that internationalization has been supported for years. Chances are good that they will skim over the new features entirely. What *is* important to these people, however, are the customer testimonials at the beginning of the press release and the list of happy customers at the end. Once management has read the press release they can ask their developers to read the Release Notes. Press releases don't supercede Release Notes, they complement them. The difference between the 7.3 Release Notes and the press release is that I could give the press release to my boss. PostgreSQL desperately needs marketing help. In fact, at this point I would say that PostgreSQL needs more marketing help than it needs development work. Technically PostgreSQL is clearly a winner, but despite its myriad features and impressive performance PostgreSQL is still not being deployed nearly as much as it *should* be. The team that has been assembled to market PostgreSQL has some fairly impressive credentials. They are certainly *much* better than what you would expect considering how much they are getting paid :). In short, if you want to help the folks writing the press releases, then that's fine and dandy. But if all you want to do is throw rocks at the people doing the marketing, then that's another story altogether. Jason Earl ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] more compile warnings
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: You would think that would catch it. My problem is that I am compiling with -O0, because I compile all day and I don't care about optimization. You should reconsider that. At -O0 gcc doesn't do any flow analysis, and thus you lose many important warnings. I'd recommend -O1 at least. Yes, I will re-add -O to my flags. When I did it I forgot it would affect warnings. In fact, I am now seeing a similar warning in python that I hadn't seen before, and others probably don't see it because they don't compile python. FYI, -O2 adds only 2 minutes to my 13 minute test script (but increases the cpu usage from 4 to 6 minutes). -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] DB Tuning Notes for comment...
Philip Warner [EMAIL PROTECTED] writes: At 03:54 PM 9/12/2002 -0500, Tom Lane wrote: FSM entries aren't needed for sequences either, so more correct is select count(*) from pg_class where relkind in ('r', 't'); presumably: select count(*) from pg_class where relkind in ('r', 't', 'i'); No, I meant what I said. Indexes don't use the FSM. (The premise of the FSM is that one bit of free space in a table is as good as any other bit; a premise quite incorrect for indexes.) regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DB Tuning Notes for comment...
At 07:01 PM 9/12/2002 -0500, Tom Lane wrote: We could make the constraint be on total space for relation entries + page entries rather than either individually, but I think that'd mostly make it harder to interpret the config setting rather than offer any real ease of administration. Perhaps doing both? And issue a warning to the logs when max_fsm_relations is borrowing from max_fsm_pages. It might be that the outstanding patches address the problem, but at the moment the choice of which relations to include is not well made when max_fsm_relations of much too small. We should at least issue a warning; but allowing max_fsm_relations to borrow from max_fsm_pages seems like a good idea, since having the number too low (with 161 relations setting it to the default of 100) is useless. Secondly, an empty database contains 98 tables, so the default setting of max_fsm_pages to 100 is way too low. The tradeoff of losing 7 pages from the map to include another relation is worth it, especially if the logs contain a warning. But perhaps the test itself is flawed and there is another problem resulting in this behaviour (doing vacuums twice in a row seems to make it use the free space, but I'd guess this is just edge behaviour of the FSM heuristics): Create Table t(i serial, t text); insert into t(t) 47K of UUEncoded jpeg file - ~47K of toast. insert into t(t) select t from t; ...repeat 9 times... create table t1 as select * from t limit 1; ... create table t19 as select * from t limit 1; create table t20(i serial, t text); insert into t20(t) select t from t; ie. build a lot of tables, with two big ones separated by OID (not sure if the last part is relevant). select count(*) from pg_class where relkind in ('t','r'); in my case this resulted in 161, so I set max_fsm_relations to 100 (ie. not a borderline case, but the default setting). I also left max_fsm_pages at 1 so that we should have space for several thousand rows. Stop start postmaster, then vacuum full to be comfortable no other problems occur, an look at file sizes of relation file and toast file. Now: delete from t where i = 128; delete from t20 where i = 128; vacuum; check file sizes - no surprises, they should be unchanged. Tue Dec 10 12:03:53 EST 2002 -rw---1 pjw users 65536 2002-12-10 12:03 16979 -rw---1 pjw users 65536 2002-12-10 12:03 33432 -rw---1 pjw users67108864 2002-12-10 12:03 16982 -rw---1 pjw users67108864 2002-12-10 12:03 33435 then do: insert into t(t) select t from t20 limit 10; insert into t20(t) select t from t limit 10; and both files have grown: Tue Dec 10 12:08:20 EST 2002 -rw---1 pjw users 65536 2002-12-10 12:08 33432 -rw---1 pjw users67764224 2002-12-10 12:08 33435 -rw---1 pjw users67764224 2002-12-10 12:08 16982 -rw---1 pjw users 65536 2002-12-10 12:08 16979 oddly (bug? edge behaviour?) doing two vacuums in a row results in the free space being used. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DB Tuning Notes for comment...
At 12:17 PM 10/12/2002 +1100, Philip Warner wrote: Secondly, an empty database contains 98 tables, Corrected based on Tom's later mail; from the FSM PoV, it contains 37 (indices don't count). So it is exhausted when more than two DBs are created. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DB Tuning Notes for comment...
Philip Warner [EMAIL PROTECTED] writes: Secondly, an empty database contains 98 tables, so the default setting of max_fsm_pages to 100 is way too low. Only 37 of them need FSM entries, but still a good point; we should probably bump it up to 1000 to be more realistic. oddly (bug? edge behaviour?) doing two vacuums in a row results in the free space being used. I'm on my way out the door, so no time to think about what's actually happening in the current code, but ideally I would think that when the FSM doesn't have enough space, it should prefer to remember info about rels with heavy update activity (which might be approximated by rels with lots of free space, but isn't really the same thing). A VACUUM done just after startup does not have any historical info to base this decision on. So it's not unreasonable for the system to make better choices after it's been running awhile than when it's freshly booted. I'm not sure that this is actually what's happening today, just pointing out that I don't consider it a bug per se if the code behaves that way. (The existing code does have some LRU effects, IIRC, but not sure if they account for what you see.) 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] DB Tuning Notes for comment...
Tom Lane wrote: Scott Shattuck [EMAIL PROTECTED] writes: Willing to learn here but skipping a vacuum full has caused some issues for us. Here's some data from a recent 3 day test run that was done with regular vacuums but not vacuum fulls. When running with vacuum full the indexes remain in line: nsuite-10=# select relname, relpages, reltuples from pg_class where relname not like 'pg_%' order by reltuples desc; -[ RECORD 1 ]-- relname | directory_fullpath_ix relpages | 96012 reltuples | 1.38114e+06 -[ RECORD 2 ]-- relname | directory_pkey relpages | 16618 reltuples | 1.38114e+06 -[ RECORD 3 ]-- relname | directory relpages | 23924 reltuples | 59578 snip blink There's no way that the index and table tuple counts should get that far out of line; in the absence of any concurrent updates, they should be *equal* (or index table, if you have a partial index, which I assume these are not). I would credit the recorded index count exceeding the recorded table count by the number of tuples inserted/ updated while a (plain) VACUUM is in process on that table --- but this doesn't look like it meets that situation. There was a bug a long time ago wherein vacuum would forget to update pg_class.reltuples for indexes in some cases, but according to the CVS logs that was fixed before 7.2 release. What version are you running exactly? test=# select version(); version - PostgreSQL 7.2.2 on i686-pc-linux-gnu, compiled by GCC 2.96 (1 row) test=# In any case, you seem to be dealing with some kind of bug here. It might be helpful to look at the output of vacuum verbose directory if you still have it available. NOTICE: --Relation directory-- NOTICE: Index directory_pkey: Pages 15628; Tuples 4988848: Deleted 35407. CPU 0.73s/3.00u sec elapsed 40.53 sec. NOTICE: Index directory_fullpath_ix: Pages 80808; Tuples 4989317: Deleted 35407. CPU 4.84s/3.91u sec elapsed 275.66 sec. NOTICE: Removed 35407 tuples in 786 pages. CPU 0.13s/0.11u sec elapsed 1.80 sec. NOTICE: Pages 80156: Changed 18, Empty 0; Tup 4988787: Vac 35407, Keep 4977704, UnUsed 348422. Total CPU 7.85s/7.58u sec elapsed 343.84 sec. regards, tom lane Thanks for any insight you can offer here. ss ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] DB Tuning Notes for comment...
At 08:39 PM 9/12/2002 -0500, Tom Lane wrote: A VACUUM done just after startup does not have any historical info to base this decision on. The actual order is: start delete vacuum; insert - does not use free space vacuum; insert - does not use free space vacuum; vacuum; insert - uses free space my guess is the fact that the second vacuum has no useful statistics means that (somehow) it is choosing the tables with free space -- perhaps because they are the largest? Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] DB Tuning Notes for comment...
On Mon, 09 Dec 2002 19:10:23 -0500, Tom Lane wrote: Philip Warner [EMAIL PROTECTED] writes: I think it would be worth looking at removing max_fsm_tables as a tuning option, and adding a 'relhasfsm' flag to pg_class for those tables that should not be mapped. Default to 't'. Then, make the table grow dynamically as tables are added, or when a VACUUM occurs... If we could make the table grow dynamically then there'd not be much need for the config parameters at all. The real problem is to fit into a shmem segment whose size has to be frozen at postmaster start (which, not incidentally, is before we've ever looked at the database...). We could make the constraint be on total space for relation entries + page entries rather than either individually, but I think that'd mostly make it harder to interpret the config setting rather than offer any real ease of administration. Can we not just have vacuum of a database return a total # of pages modified and relations modified, and then report suggested free space map settings? Even this little bit would be a step in the right direction. Robert Treat ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] DB Tuning Notes for comment...
At 09:10 PM 9/12/2002 -0500, Robert Treat wrote: Even this little bit would be a step in the right direction. What I would find really useful is a 'VACUUM...WITH HISORY' which wrote the underlying details of VACUUM VERBOSE to a 'pg_vacuum_history' table. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] nested transactions
Bruce Momjian wrote: I am going to work on nested transactions for 7.4. My goal is to first implement nested transactions: BEGIN; SELECT ... BEGIN; UPDATE; COMMIT; DELETE; COMMIT; and later savepoints (Oracle): BEGIN; SELECT ... SAVEPOINT t1; UPDATE; SAVEPOINT t2; DELETE; ROLLBACK TO SAVEPOINT t2; COMMIT; I assume people want both. Yep. My question is: how do you see cursors working with nested transactions? Right now you can't do cursors outside of transactions. Subtransactions would complicate things a bit: BEGIN; DECLARE CURSOR x ... BEGIN (is cursor x visible here? What are the implications of using it if it is?) ... COMMIT; ... COMMIT; Would we only allow cursors within the innermost transactions? If we allow them anywhere else, why retain the requirement that they be used within transactions at all? -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Jason Earl [EMAIL PROTECTED] writes: Peter Eisentraut [EMAIL PROTECTED] writes: Compare the 7.3 release notes, written for the most part by Bruce Momjian and revised by a couple of other developers, to the press release, written by people who were obviously ill-informed. So does this mean that you are volunteering to proofread the next marketing announcement? I would wager that only a PostgreSQL developer (such as yourself) could have picked out the inconsistencies that you were able to find. FWIW, the press release looked fine to me too (and yes, I saw it in advance). The difference between the press release and the Release Notes is the intended audience. Exactly. The level of detail in the release notes is aimed at hackers (and usually gets criticized as insufficient by them ;-)), but a press release has entirely different purposes. In short, if you want to help the folks writing the press releases, then that's fine and dandy. One error that I think the advocacy team made is that they didn't invite review of the press release from a wider part of the community. Although I generally agree with the viewpoint that marketing issues should be on a separate list and not on -hackers or -general, I think it wouldn't be out of place to send one message to those lists saying a draft of the press release for event FOO is up at this URL, please send comments to advocacy mail list. That seems like a reasonable compromise between filling the lists with unwanted material and having people feel that they were excluded from the process. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Josh Berkus writes: I can definitely understand someone not wanting to *participate* in marketing/advocacy of PostgreSQL. However, your being opposed to promoting PostgreSQL as an organized activity *at all* baffles me. How can you be against promoting PostgreSQL? I'm not against promoting PostgreSQL. I'm against promoting PostgreSQL in ways that embarrass me. -- Peter Eisentraut [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] PostgreSQL Global Development Group
Peter, I can definitely understand someone not wanting to *participate* in marketing/advocacy of PostgreSQL. However, your being opposed to promoting PostgreSQL as an organized activity *at all* baffles me. How can you be against promoting PostgreSQL? I'm not against promoting PostgreSQL. I'm against promoting PostgreSQL in ways that embarrass me. What, specifically, were you embarassed by? -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] psql's \d commands --- end of the line for 1-character identifiers?
[ moved to hackers from pgsql-patches ] Christopher Kings-Lynne [EMAIL PROTECTED] writes: Peter wrote: Christopher Kings-Lynne writes: \dc - list conversions [PATTERN] \dC - list casts What are we going to use for collations? \dn Is the only letter left in collations that hasn't been used! ... and that was already proposed for show schemas (namespaces). I'm inclined to think it's time to bite the bullet and go over to words rather than single characters to identify the \d target (viz, \dschema, \dcast, etc, presumably with unique abbreviations being allowed, as well as special cases for the historical single characters). The issue here is what do we do with the existing \d[istvS] behavior (for instance, \dsit means list sequences, indexes, and tables). Is that useful enough to try to preserve, or do we just bit-bucket it? If we do try to preserve it, how should it work? 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] Sequence Cleanup
Rod Taylor kirjutas T, 10.12.2002 kell 01:49: Below is a short list of TODOs on sequences I wish to tackle over the next week. ... Ok, this is where it gets confusing. Right now setval() is implemented in such a manner that it cannot be rolled back (see SETVAL NOTE below), but I'd like ALTER SEQUENCE to be transaction safe. All *val('seqname') functions are transaction-unsafe, i.e. live outside transactions. Why would you want alter transaction to be transaction safe ? -- Hannu Krosing [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] proposal: array utility functions phase 1
Tom Lane wrote: This seems fairly unworkable to me as-is. By definition, WHERE selects from a cross-product of the FROM tables; to make the above do what you want, you'd have to break that fundamental semantics. The semantics of explicit JOIN cases would be broken too. What we need is some kind of explicit multi-level SELECT operation. Perhaps it would help to think about the analogy of aggregates of aggregate functions, which are impossible to express properly in a single SELECT but work nicely given subselect-in-FROM. Subselect-in-FROM doesn't seem to get this job done though. Right offhand I don't see any reasonable syntax other than function-in-the-SELECT-list, which shoots us right back into the messinesses of the Berkeley implementation. However, we do now have the precedent of the table-function AS clause. Does it help any to do something like SELECT grosysid, array_values(grolist) AS (array_index,member_id) FROM pg_group where groname = 'g2'; After further thought, and ignoring the difficulty of implementation, what seems ideal is to be able to specify 'setof datatype' or 'setof composite-type' as an input to the function, and fire the function once for each row of the input. Basically, allow anything that now qualifies as a FROM item -- a table reference, a subselect with AS clause, another table function, or maybe even a join clause. Some (totally contrived) examples of how it would look: create table foo1(f1 int, f2 text); insert into foo1 values(1,'a'); insert into foo1 values(2,'b'); insert into foo1 values(3,'c'); create table foo2(f1 int, f2 text); insert into foo2 values(1,'w'); insert into foo2 values(1,'x'); insert into foo2 values(2,'y'); insert into foo2 values(2,'z'); create function funcfoo1(setof foo1) returns setof foo2 as 'select * from foo2 where foo2.f1 = $1.f1' language 'sql'; select * from funcfoo1(foo1); f1 f2 +- 1 | w 1 | x 2 | y 2 | z select * from funcfoo1((select * from foo1 where f1=1) as t); f1 f2 +- 1 | w 1 | x What do you think? (Again you could wrap this in an outer SELECT to transform the member_ids to member_names.) The real problem with the Berkeley approach shows up when you consider what happens with multiple table functions called in a single SELECT. The code we currently have produces the cross-product of the implied rows (or at least it tries to, I seem to recall that it doesn't necessarily get it right). That's pretty unpleasant, and though you can filter the rows in an outer SELECT, there's no way to optimize the implementation into a smarter-than-nested-loop join. What if there was a way to declare that a table function returns sorted results, and on which column(s)? It seems like somehow we need a level of FROM/WHERE producing some base rows, and then a set of table function calls to apply to each of the base rows, and then another level of WHERE to filter the results of the function calls (in particular to provide join conditions to identify which rows to match up in the function outputs). I don't see any way to do this without inventing new SELECT clauses out of whole cloth ... unless SQL99's WITH clause helps, but I don't think it does ... Is this still needed given my approach above? How ugly/difficult would it be to allow the planner to interrogate the function and let the function report back a tupledesc based on the actual runtime input parameters? Parse-time, not run-time. It could be done --- IIRC, the auxiliary function info call we introduced in the V1 fmgr protocol was deliberately designed to allow expansion in this sort of direction. But it would have to take a tupledesc (or some similar static description) and return another one. Nice! I'll dig in to that a bit. Thanks, Joe ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[HACKERS] tuple descriptors?
Can anyone tell me how to get a tuple's TupleDesc if all that is known is the tid? Or is there an easy way to step through a tuple, retrieving the data and data type from each field? Thanks, Nate Sommer
Re: [HACKERS] tuple descriptors?
Nate Sommer [EMAIL PROTECTED] writes: Can anyone tell me how to get a tuple's TupleDesc if all that is known is t= he tid? Or is there an easy way to step through a tuple, retrieving the da= ta and data type from each field? Tupledescs are generally associated with tables (relations) more easily than with specific tuples. What exactly is your context here? regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Let's create a release team
On 9 Dec 2002 at 11:38, Tom Lane wrote: Dan Langille [EMAIL PROTECTED] writes: Let's create a release team. This strategy is one well established in other projects and in industry. For lack of a better starting reference, let me suggest http://www.freebsd.org/releng/charter.html as a starting point for consideration. See also http://www.freebsd.org/releng/index.html. This will also lighten the load on the core team allowing them to focus on development and such. I don't really see any value-added here. The core committee's only routinely-exercised function is to organize releases; separating that out would leave core with nothing to do. So we already have a release team, but not titled as such. Also, to the extent that core has any real or perceived authority in the project, I think it comes from having control of the release process --- there's surely no other reason for people to defer to the core team as a group (as opposed to whatever respect might be accorded to individual people as a result of their individual contributions). Is the process documented? Any set procedure? Who knows how to do it? So ISTM such a reorganization would leave the core committee as a figurehead and make the release team into the effective new core. Is 'core' the same as 'steering'? I couldn't find any reference to core committe or core team via google. At http://developer.postgresql.org/bios.php I see the group of people referred to as Steering. Is their function defined anywhere? If these things are not documented, they should be. Where do I start? -- Dan Langille : http://www.langille.org/ ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] tuple descriptors?
Can anyone tell me how to get a tuple's TupleDesc if all that is known is t= he tid? Or is there an easy way to step through a tuple, retrieving the da= ta and data type from each field? Tupledescs are generally associated with tables (relations) more easily than with specific tuples. What exactly is your context here? regards, tom lane I'm a student taking a database systems course, and as a project option I chose to work on one of PostgreSQL's todo list items, namely auto-delete large objects when referencing row is deleted. The main point of the project is to become more comfortable tackling large amounts of code. Working through the PostgreSQL code has been very interesting, and thus far I've worked independently, but now I'm getting a little overwhelmed. What I'd like to do is add some code to the heap_delete function that checks the tuple being deleted for oids, compares those oids to the loids in the pg_largeobject relation, and deletes rows accordingly. I thought using TupleDescs would be helpful, but I guess my understanding of them is off. Nate Sommer ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql's \d commands --- end of the line for 1-character identifiers?
... and that was already proposed for show schemas (namespaces). I'm inclined to think it's time to bite the bullet and go over to words rather than single characters to identify the \d target (viz, \dschema, \dcast, etc, presumably with unique abbreviations being allowed, as well as special cases for the historical single characters). Hmmm...I'm not certain that the \d commands really NEED to have a logical link to the actual thing you're listing. If you just made \dh for schemas, people would look it up and then remember it from then on. It's probably not a huge deal. We could do DESCRIBE commands as well. Also, what happened to the INFORMATION_SCHEMA proposal? Wasn't Peter E doing something with that? What happened to it? The issue here is what do we do with the existing \d[istvS] behavior (for instance, \dsit means list sequences, indexes, and tables). Is that useful enough to try to preserve, or do we just bit-bucket it? If we do try to preserve it, how should it work? I'd much rather it were preserved, and I'm sure most people would as well. Chris ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] psql's \d commands --- end of the line for
Tom Lane kirjutas T, 10.12.2002 kell 02:05: [ moved to hackers from pgsql-patches ] Christopher Kings-Lynne [EMAIL PROTECTED] writes: Peter wrote: Christopher Kings-Lynne writes: \dc - list conversions [PATTERN] \dC - list casts What are we going to use for collations? \dn Is the only letter left in collations that hasn't been used! ... and that was already proposed for show schemas (namespaces). I'm inclined to think it's time to bite the bullet and go over to words rather than single characters to identify the \d target (viz, \dschema, \dcast, etc, presumably with unique abbreviations being allowed, as well as special cases for the historical single characters). The issue here is what do we do with the existing \d[istvS] behavior (for instance, \dsit means list sequences, indexes, and tables). Is that useful enough to try to preserve, or do we just bit-bucket it? If we do try to preserve it, how should it work? Why not use \D for long ids ? Somewhat similar to -? and --help for command line. -- Hannu Krosing [EMAIL PROTECTED] ---(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] Darwin/Mac OS X Startup Script
Added to /contrib/start-scripts as: PostgreSQL.darwin StartupParameters.plist.darwin Thanks. --- David Wheeler wrote: All, I've simplified the Darwin/Mac OS X startup script I submitted earlier in the year. This version has only the two files required by the Darwin startup bundle design. Plus the sh script now uses Darwin-standard functions to start up PostgreSQL, and it checks for the presence of a variable in /etc/hostconfig, as do other Darwin startup scripts. I suggest that a new directory be created, contrib/start-scripts/darwin, and that these two files be put into it. Folks who want to use the script can read the comments inside it to figure out how to use it. Enjoy, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] [ Attachment, skipping... ] ---(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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Let's create a release team
Hi Dan, It's been mentioned a few times on the Advocacy and Marketing list that we should put together a process for ensuring that all the parts necessary for a release occur properly and smoothly. *** Source code - Initial packaging of the new releases' source code Docs - Confirm with Peter that the Docs are 100% correct in the new source archive RPM's SRPM's - Co-ordinate with Lamar to have these ready before the general announcement? Press Releases for the General Public (multiple languages) - Advocacy and Marketing guys should put together a Press Release intended for the General Public, and have it reviewed/confirmed by the Hackers before getting it ready - Robert (?) should arrange translation of this confirmed good Press Release into multiple languages Press Release for the Technically Minded (?) - Advocacy and Marketing guys (?) should put together a Press Release intended for the Hackers and other Technically Minded folk. Should definitely be reviewed for accuracy by the Hackers before releasing it Websites - Ensure all of the required documentation mentions, links, release info, etc is put in place on the website Mailout - Email the appropriate Press Releases to the General Public, and to the Technically Minded groups Feedback - Find out what could have been done better, and figure out how to make it so for the next one if appropriate *** That was just what came to mind and there's probably more. Each part should probably be something that can be broken down into the necessary parts so that everyone can take care of the bits they're into. I suppose it would be good to have this listed somewhere so that people can make suggestions. Just whipped up a page listing these main points here, and everyone has the ability to make suggestions/edits directly onto that page: http://advocacy.postgresql.org/documents/ReleaseProcess Hopefully that's helpful. :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(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] tuple descriptors?
Nate Sommer [EMAIL PROTECTED] writes: Tupledescs are generally associated with tables (relations) more easily than with specific tuples. What exactly is your context here? What I'd like to do is add some code to the heap_delete function that checks the tuple being deleted for oids, compares those oids to the loids in the pg_largeobject relation, and deletes rows accordingly. Ah. Well, heap_delete has trivial access to the appropriate tupledesc: relation-rd_att (or more cleanly RelationGetDescr(relation)) gives it to you. Not sure how large a can of worms you wanted to open here, but some creepy-crawlies I can finger offhand include: * don't forget heap_update's obsoleted tuple (but only when the replacement tuple contains a different LO oid). * [ extra credit ] don't forget heap_truncate. (If you can figure out how to do this bit without sacrificing the fundamental performance advantage of heap_truncate, then you're wasting your time dealing with us mere mortals...) * scanning pg_largeobject anytime someone wants to delete a tuple that includes an OID will be a serious performance hit, especially for updates on system catalogs --- it could even open the potential for deadlocks. Not to mention the obvious infinite-recursion problem: pg_largeobject itself has an OID column. Possibly you could finesse most of these issues by only doing the special processing for lo columns not oid columns, but that seems like a cheat. Is there a better way? * OIDs are not guaranteed unique across different system catalogs. Maybe there isn't a better way --- certainly deleting LO 42 because someone deleted pg_proc 42 wouldn't be happy-making. Within the catalogs we take care to know from context which catalog an OID must refer to, but a trigger that works on any OID column is at risk. You've done pretty well already to identify heap_delete as a plausible place to hack this, though. Soldier on ... 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] Let's create a release team
Dan Langille [EMAIL PROTECTED] writes: Is the process documented? Any set procedure? Who knows how to do it? Er ... nope, nope, the core bunch ... Is 'core' the same as 'steering'? Yes, the webpage takes some license here. 'core' is the most common terminology for the-usual-suspects. I'm not sure where 'steering' came from, but it's the same suspects... If these things are not documented, they should be. Most of the undocumented details of the release process are in the heads of Marc Fournier and Bruce Momjian. If either of them falls off the end of the earth, we have worse troubles than whether we remember how to do a release --- for example: Marc owns, runs, and pays for the postgresql.org servers. (Me, I just hack code, so I'm replaceable.) But if you want to try to document the process better, there are some details written down already (eg, src/tools/RELEASE_CHANGES) and I'm sure Marc and Bruce would cooperate in writing down more. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Let's create a release team
Tom Lane wrote: as a result of their individual contributions). So ISTM such a reorganization would leave the core committee as a figurehead and make the release team into the effective new core. I thought we were already only figureheads? ;-) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [HACKERS] tuple descriptors?
Nate Sommer [EMAIL PROTECTED] writes: I'm a student taking a database systems course, and as a project option I chose to work on one of PostgreSQL's todo list items, namely auto-delete large objects when referencing row is deleted. The main point of the project is to become more comfortable tackling large amounts of code. BTW, I went to a pretty outstanding tutorial on just that topic this past summer at OSCON: Glenn Vanderburg on Using the Source: Software Archaeology for Users of Open Source Software (http://conferences.oreillynet.com/cs/os2002/view/e_sess/2869) which could be described in two seconds as don't be afraid to get your hands dirty, and in full length as how to be effective while doing so. The pikers at O'Reilly seem not to have made Glenn's slides available on-line (isn't this a direct violation of their speakers' agreement? Mine are there...) but I'm sure Glenn would be pleased to send 'em to you on request. 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] tuple descriptors?
At 01:56 AM 10/12/2002 -0500, Tom Lane wrote: but I'm sure Glenn would be pleased to send 'em to you on request. Do you have an email address - the O'Reilly site also seems not to have one... Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] tuple descriptors?
At 01:56 AM 10/12/2002 -0500, Tom Lane wrote: but I'm sure Glenn would be pleased to send 'em to you on request. I've found a link: http://www.delphis.com/java/java.html Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] tuple descriptors?
Philip Warner [EMAIL PROTECTED] writes: At 01:56 AM 10/12/2002 -0500, Tom Lane wrote: but I'm sure Glenn would be pleased to send 'em to you on request. Do you have an email address - the O'Reilly site also seems not to have one... Hrm, you're right. I think there was one in the hardcopy slides, but that's not beside me at the moment. Before we deluge Glenn with requests, let me ask him for a URL on behalf of the group ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql's \d commands --- end of the line for
Hannu Krosing [EMAIL PROTECTED] writes: Why not use \D for long ids ? Seems like a fine idea to me. (I had actually started to think of \ssomething for show, but was just observing that that would create conflicts against existing commands, when your message arrived. \Dsomething works though.) Any objections out there? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group Announces
On Thu, 5 Dec 2002, Tom Lane wrote: I tend to agree with Peter. Not that we don't need a marketing presence; we do (I think Great Bridge's marketing efforts are sorely missed). But the point he is making is that the pgsql mailing lists go to people who are generally unimpressed by marketing fluff. And they're already sold on PG anyway. The right way to handle this next time is to generate a PR-style press release to send to outside contacts, but to do our more traditional, technically-oriented announcement on the mailing lists. Agreed ... we tried to do 'two-in-one' on this one and it didn't quite work out as well as it could have ... next time, we'll go with both methods ... ---(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] PostgreSQL Global Development Group Announces
On Sat, 7 Dec 2002, Vince Vielhaber wrote: On Wed, 4 Dec 2002, Bruce Momjian wrote: Peter Eisentraut wrote: Marc G. Fournier writes: It isn't, but those working on -advocacy were asked to help come up with a stronger release *announcement* then we've had in the past ... Consider that a failed experiment. PostgreSQL is driven by the development group and, to some extent, by the existing user base. The last thing we need is a marketing department in that mix. Peter, I understand your perspective, but I think you are in the minority on this one. Kinda depends who you're asking now, doesn't it? I happen to agree with him, but as long as you're only going to involve a selected few in the opinion gathering you can pretty much get the answer you want to get. I can survey 100 people and get the opposite result putting you in the minority. Me, I think Peter went to the 'far left', while the press release went to the 'far right' (or vice versa) ... i think Tom sum'd it up best that we should have had one for each 'market' we were trying to address ... definitely something to keep in mind and strive for for the next release ... ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
s'alright, the 'fiefdoms' are about to be nuked :) On Thu, 5 Dec 2002, Robert Treat wrote: On Thu, 2002-12-05 at 03:28, Dave Page wrote: www is a closed group consisting of a few of us who actually do the work on the sites. This is one of the primary reasons the sites are so fractured. We have 4 different mailing lists for website development (and I'm not counting advocacy as one of those) and the folks maintaining those lists seem to be against letting anyone into their fiefdoms. Robert Treat ---(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 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql's \d commands --- end of the line for
At 05:13 PM 9/12/2002 -0500, Tom Lane wrote: Seems like a fine idea to me. Ditto. \Dsomething works though.) Any objections out there? My only complaint here is being forced to use the 'shift' key on commands that will be common. I would prefer any other lower case char: \b, \j, \k , \m, \n, \u, \v, and \y are available. I'd vote for \v (view), or \k (command). The go with: \v schema or \k show schema (I'd vote for \v). Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] PostgreSQL Global Development Group
Peter Eisentraut wrote: snip Press release: - Supports data in many international characters sets (UNICODE, EUC_JP, EUC_CN, EUC_KR, JOHAB, EUC_TW, ISO 8859-1 ECMA-94, KOI8, WIN1256, etc...) That is just plain wrong. Support for various character sets is years old. Sure is. Notice it didn't say just added or added with this release? It just says supports. It's to highlight the fact that it can be used for non-English character sets. Sure, a whole bunch of people know this, but the main target of the press release is people new to PostgreSQL that don't. :-) Regards and best wishes, Justin Clift -- My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there. - Indira Gandhi ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Peter, Robert, Jason, Vince, Justin, et al.: First off, I'd like to ask everyone to CUT IT OUT WITH THE $^*^@** FLAMING, ALREADY! People are *attacking* each other instead of disagreeing. Several posters seem to be taking to opportunity to say everything in the most insulting way possible, even when the actual source of disagreement is small. Perhaps we should declare a moritorium on this topic for 48 hours to let everyone calm down? In case we don't, my response: PETER, it's obvious that the press release team would have benefitted from your copy-editing of the press release.You have several good points about places where we did not do the best possible job in the difficult task of translating technical notes into a form the general press would understand. I wrote a lot of the paragraphs you take issue with, and I don't deny that they could stand improvement. Would you be willing to act as a reviewer on future press releases? That way, we can get the benefit of your insight in a manner that will benefit the press release process. -- -Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [GENERAL] PostgreSQL Global Development Group
Josh Berkus [EMAIL PROTECTED] writes: First off, I'd like to ask everyone to CUT IT OUT WITH THE $^*^@** FLAMING, ALREADY! People are *attacking* each other instead of disagreeing. Amen. This was first time 'round for the advocacy group, and it's not surprising that there are some things they did wrong, or at least could have done better. Can't we discuss the matter like a group of reasonably friendly people? I think we all have the same end goals in mind, so I don't see the need for unpleasantness. 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] psql's \d commands --- end of the line for 1-character
Christopher Kings-Lynne wrote: We could do DESCRIBE commands as well. Also, what happened to the INFORMATION_SCHEMA proposal? Wasn't Peter E doing something with that? What happened to it? The issue here is what do we do with the existing \d[istvS] behavior (for instance, \dsit means list sequences, indexes, and tables). Is that useful enough to try to preserve, or do we just bit-bucket it? If we do try to preserve it, how should it work? I'd much rather it were preserved, and I'm sure most people would as well. I was going to say the opposite, that it isn't needed. Oh well. -- 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] [GENERAL] PostgreSQL Global Development Group
Tom Lane wrote: Josh Berkus [EMAIL PROTECTED] writes: First off, I'd like to ask everyone to CUT IT OUT WITH THE $^*^@** FLAMING, ALREADY! People are *attacking* each other instead of disagreeing. Amen. This was first time 'round for the advocacy group, and it's not surprising that there are some things they did wrong, or at least could have done better. Can't we discuss the matter like a group of reasonably friendly people? I think we all have the same end goals in mind, so I don't see the need for unpleasantness. Agreed. Here's a story: Myself and a few people wanted live animals for a manger scene on our church lawn for Christmas. Many thought it was a bad idea, but we went ahead anyway. It was a huge success, but then people complained we didn't have enough people on the lawn to greet the hundreds of visitors. Moral of the story: if you take risks, expect folks to complain. And, even if you succeed, others will complain you didn't anticipate the success. -- 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 4: Don't 'kill -9' the postmaster
Re: [HACKERS] psql's \d commands --- end of the line for
At 01:22 PM 9/12/2002 -0800, Christopher Kings-Lynne wrote: Hmmm...I'm not certain that the \d commands really NEED to have a logical link to the actual thing you're listing. This is the perspective a person with good memory, unlike me. In find it useful to be able to derive commands from common-sense rules, even if it means a little more typing. We could do DESCRIBE commands as well. Also, what happened to the This would be fine, so long as the standard does not get in the way of displaying postgres-specific information (eg. function attrs). Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] nested transactions
Kevin Brown wrote: My question is: how do you see cursors working with nested transactions? Right now you can't do cursors outside of transactions. Subtransactions would complicate things a bit: BEGIN; DECLARE CURSOR x ... BEGIN (is cursor x visible here? What are the implications of using it if it is?) ... COMMIT; ... COMMIT; Would we only allow cursors within the innermost transactions? If we allow them anywhere else, why retain the requirement that they be used within transactions at all? I talked to Tom and he feels it will be too hard to rollback a subtransaction that affects cursors so we will disable use of cursors in subtransactions, at least in the first implementation. -- 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] psql's \d commands --- end of the line for
On Tue, Dec 10, 2002 at 12:55:51PM +1100, Philip Warner wrote: At 01:22 PM 9/12/2002 -0800, Christopher Kings-Lynne wrote: Hmmm...I'm not certain that the \d commands really NEED to have a logical link to the actual thing you're listing. This is the perspective a person with good memory, unlike me. In find it useful to be able to derive commands from common-sense rules, even if it means a little more typing. Would it work to make \d tab-completable in a way that showed both the commands that are available and the objects they describe? e.g. \dtab would show something like \dt [tables]\ds [sequences] \dv [views] ... (the way it's shown now shows what completions are available, but not what they mean. Also, both \d and \D should be shown in any case) -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) Los romanticos son seres que mueren de deseos de vida ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql's \d commands --- end of the line for
\Dsomething works though.) Any objections out there? My only complaint here is being forced to use the 'shift' key on commands that will be common. \dd perhaps? ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] psql's \d commands --- end of the line for
At 01:55 AM 10/12/2002 -0300, Alvaro Herrera wrote: \dtab would show something like \dt [tables]\ds [sequences] \dv [views] ... (the way it's shown now shows what completions are available, but not what they mean. Also, both \d and \D should be shown in any case) This would be OK, but I'd be very happy with DESCRIBE, especially if tab-completion meant I could type 'DESCtabTABtabname' instead of 'DESCRIBE TABLE name'. Philip Warner| __---_ Albatross Consulting Pty. Ltd. |/ - \ (A.B.N. 75 008 659 498) | /(@) __---_ Tel: (+61) 0500 83 82 81 | _ \ Fax: (+61) 03 5330 3172 | ___ | Http://www.rhyme.com.au |/ \| |---- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/ ---(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] psql's \d commands --- end of the line for
Philip Warner [EMAIL PROTECTED] writes: This would be OK, but I'd be very happy with DESCRIBE, especially if tab-completion meant I could type 'DESCtabTABtabname' instead of 'DESCRIBE TABLE name'. That's quicker than backslashshiftDunshifttspacename ? I don't want to sound like I've got some kind of religious objection to DESCRIBE, but it was just a couple of hours ago that someone was objecting to \D because it'd require touching the shift key. Let's get a bit realistic on the ease-of-typing arguments here. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] [ADMIN] dumpProcLangs(): handler procedure for language
I have had similar troubles, related to oid overflow. I had to modify pg_dump to properly cast queries that contain oids. This is against 7.1.3 source. The patch was hacked quickly, in order to get a corrupted database reloaded, and this while I was traveling in another country... so it is far from perfect but saved my database(s). It also fixes other oid-related troubles of pg_dump. See attached file. Daniel Brian Fujito said: Thanks for your input-- I've tried both ways: createlang/droplang from the command line as user postgres and: CREATE FUNCTION plpgsql_call_handler () RETURNS OPAQUE AS '/usr/lib/pgsql/plpgsql.so' LANGUAGE 'C'; CREATE TRUSTED PROCEDURAL LANGUAGE 'plpgsql' HANDLER plpgsql_call_handler LANCOMPILER 'PL/pgSQL'; I'm using pg_dump (not pg_dumpall) on the specific database on which I created the language. I realize 7.0.3 is ancient (same with 7.1)... I just don't have the time to deal with an upgrade quite yet. Soon enough :) In the mean time, a stop-gap solution would definitely be appreciated. Thank you, Brian On Mon, 2002-12-09 at 14:28, Tom Lane wrote: Brian Fujito [EMAIL PROTECTED] writes: I'm running postgres-7.0.3 on RH7.1 using RedHat RPMs. I recently added plpgsql as a language to one of my databases, and now when I try to do a pg_dump, I get: dumpProcLangs(): handler procedure for language plpgsql not found If I drop the language, pg_dump works fine, but if I add it back (and even if I restart postgres), I get the same error. What exactly are you doing to drop and re-add the language? I should think CREATE LANGUAGE would fail if the handler proc isn't there. (Also, are you doing pg_dump or pg_dumpall? If the latter, maybe the failure is occurring in a different database than the one you are changing.) But having said that, 7.0.3 is ancient history ... you really are overdue for an upgrade. With my Red Hat fedora on, I'd say the same about your choice of OS version too. 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 *** pg_dump.c.orig Mon Apr 15 09:45:58 2002 --- pg_dump.c Tue Jun 25 00:23:53 2002 *** *** 2006,2012 finfo[i].prorettype = strdup(PQgetvalue(res, i, i_prorettype)); finfo[i].retset = (strcmp(PQgetvalue(res, i, i_proretset), t) == 0); finfo[i].nargs = atoi(PQgetvalue(res, i, i_pronargs)); ! finfo[i].lang = atoi(PQgetvalue(res, i, i_prolang)); finfo[i].usename = strdup(PQgetvalue(res, i, i_usename)); finfo[i].iscachable = (strcmp(PQgetvalue(res, i, i_iscachable), t) == 0); finfo[i].isstrict = (strcmp(PQgetvalue(res, i, i_isstrict), t) == 0); --- 2006,2012 finfo[i].prorettype = strdup(PQgetvalue(res, i, i_prorettype)); finfo[i].retset = (strcmp(PQgetvalue(res, i, i_proretset), t) == 0); finfo[i].nargs = atoi(PQgetvalue(res, i, i_pronargs)); ! finfo[i].lang = atooid(PQgetvalue(res, i, i_prolang)); finfo[i].usename = strdup(PQgetvalue(res, i, i_usename)); finfo[i].iscachable = (strcmp(PQgetvalue(res, i, i_iscachable), t) == 0); finfo[i].isstrict = (strcmp(PQgetvalue(res, i, i_isstrict), t) == 0); *** *** 2289,2295 resetPQExpBuffer(query); appendPQExpBuffer(query, ! SELECT Oid FROM pg_index i WHERE i.indisprimary AND i.indrelid = %s , tblinfo[i].oid); res2 = PQexec(g_conn, query-data); if (!res2 || PQresultStatus(res2) != PGRES_TUPLES_OK) --- 2289,2295 resetPQExpBuffer(query); appendPQExpBuffer(query, ! SELECT Oid FROM pg_index i WHERE i.indisprimary AND i.indrelid = oid(%s) , tblinfo[i].oid); res2 = PQexec(g_conn, query-data); if (!res2 || PQresultStatus(res2) != PGRES_TUPLES_OK) *** *** 2328,2340 appendPQExpBuffer(query, SELECT c.relname FROM pg_index i, pg_class c ! WHERE i.indrelid = %s
Re: [HACKERS] PostgreSQL 7.3 Installation on SCO
It should have worked, but edit Makefile.shlib and remove that offending export from the link line. That may fix it. --- Shibashish wrote: Dear Sir, I use SCO Open Server 5.0.5 on an intel box. Although I have installed and used PostgreSQL on Linux, setting it on SCO has not been successful :$ I have downloaded the latest version ie Postgresql-7.3 I have also tried installing postgresql-7.1 and postgresql-7.2.3, but never succeeded. I also installed ant package for using java. I have tcl8.0, tk8.0, itclsh3.0 and itkwish3.0 installed in my system. gcc version 2.7.2.1 Java 2 SDK, Standard Edition, v. 1.2.1 GNU Make 3.80 My configure command was as following ... ./configure --prefix=/data/pgsql --with-perl --with-tcl --with-tclconfig=/data/tcl/lib/ --with-tkconfig=/data/tk/lib/ --with-java --without-readline --without-zlib The output has been attached as file configoutput.txt Then i give the make command. The compiling stops on an error and exits after some time. The output has been attached as file makeoutput.txt I'd be thankful to you if you can help me out sort the problem. I got your mail-ids from the net and came to know that you are working on the similar lines. Also, in the file doc/FAQ_SCO, does the section Compiling PostgreSQL 7.1 with the UDK apply to release 7.3 of Postgresql ? I am not using UDK. Waiting for a quick response from your end. kindly inform me if you have already solved the problem, or whether any patch is available. Any documentation or url will be highly helpful. Thanking You in anticipation. with regards Shibashish [EMAIL PROTECTED] On Yahoo Messenger : shib_leo Software Engineer IIT Bombay, India. Content-Description: [ Attachment, skipping... ] Content-Description: [ Attachment, skipping... ] Content-Description: [ Attachment, skipping... ] -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html