Re: [HACKERS] memory context for tuplesort return values
On Thu, 2006-02-23 at 16:10 -0500, Tom Lane wrote: I don't want to give up the idea of keeping sort-local data in a private context --- it just seems cleaner, as well as faster, than letting it be mixed into the caller's stuff. I can see two alternatives: Would that be a single context for all sort operations, or a separate context for each sort within a plan? There is some evidence that high sort memory is not that useful during the final merge phase. Would it be possible to have multiple contexts within each sort e.g. Run Forming context and Final Merge context? That would then allow us to more easily free the Run Forming context before moving into the final context with a potentially different size. Best Regards, Simon Riggs ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] textToQualifiedNameList second parameter
Hello In version 7.4.x, the function textToQualifiedNameList was defined with two parameters. Some months ago, the second parameter was removed [1] so I had to modify my program to work after this change. Now with 8.0.7, the second parameter is back again and I get this error when I try to compile: pg_dbsize.c: In function `relation_size': pg_dbsize.c:295: too few arguments to function `textToQualifiedNameList' make: *** [pg_dbsize] Error 1 Is the second parameter back again? [1]: http://archives.postgresql.org/pgsql-patches/2005-05/msg00307.php -- Rafael Martinez, [EMAIL PROTECTED] Center for Information Technology Services University of Oslo, Norway PGP Public Key: http://folk.uio.no/rafael/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3
Tom Lane wrote: Albert Chin [EMAIL PROTECTED] writes: On Sun, Feb 19, 2006 at 11:32:53PM -0500, Tom Lane wrote: Would you try the patch proposed at http://archives.postgresql.org/pgsql-patches/2006-01/msg00299.php Works fine on Tru64 UNIX 4.0D and 5.1. OK, applied to HEAD and 8.1. I'm feeling a bit of concern though after re-reading the comment attached to the test: # (Note: the AC_TRY_LINK probe fails on Windows, where the available # versions of getaddrinfo don't follow normal C call protocol. This is OK # because we want to use our own getaddrinfo.c on Windows anyway.) It seems likely that the new coding will allow the test to *succeed* on Windows. Does that happen, and if so is it bad? We can put in a hack to suppress the test on Windows if necessary. Someone please check it out on Windows ... It would be bad - the whole thing is that on Windows we need to search for some functions dynamically, so we have to use our own code to do that. But it appears not to find it either with ipv6 installed or not. So I think we're good (fingers crossed). cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] User privileges-verification required
Hello all, While playing around with database users, I noticed one odd thing regarding user privileges. In case I have only one user in my database who is also the DBSystem (who carries out initdb), user then if that user takes away his createuser privileges, he is unable to grant himself that privilege again or grant that privilege to any other user that he creates.This creates quite a fix since you end up with no superusers, nor a way to create any other superusers. In my opinion we should cater for such a situation, and two possible solutions come to my mind for this: 1. Place a restriction that there should be more than one superuser before you can issue a NOCREATEUSER command. 2 Only the DBsystemuser should be allowed to grant and revoke the createuser privileges. Let me know what you all think. Thanks, Nauman ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] User privileges-verification required
Am Freitag, 24. Februar 2006 14:25 schrieb Nauman Naeem: In case I have only one user in my database who is also the DBSystem (who carries out initdb), user then if that user takes away his createuser privileges, he is unable to grant himself that privilege again or grant that privilege to any other user that he creates.This creates quite a fix since you end up with no superusers, nor a way to create any other superusers. Shut down the server, start in single-user mode, then you can fix it. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] User privileges-verification required
I tried the single-user mode option and it worked, thanks! but, don't you people think that we should provide this privilege in multi-user mode as well.In accordence to my second point. On 2/24/06, Peter Eisentraut [EMAIL PROTECTED] wrote: Am Freitag, 24. Februar 2006 14:25 schrieb Nauman Naeem: In case I have only one user in my database who is also the DBSystem (who carries out initdb), user then if that user takes away his createuser privileges, he is unable to grant himself that privilege again or grant that privilege to any other user that he creates.This creates quite a fix since you end up with no superusers, nor a way to create any other superusers. Shut down the server, start in single-user mode, then you can fix it. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] fsutil ideas
The code in question is written as C extension functions. I think we were thinking it might be something for contrib (although perhaps that would be too much of an official blessing too?) Pete Jim C. Nasby [EMAIL PROTECTED] 02/24/06 8:04 am Isn't this something that could be accomplished entirely within a function? I suppose it might have to be an untrusted language, but that still seems cleaner than putting it in the backend. Plus, ISTM that something like perl is more likely to have a cross-platform means of accomplishing this. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] fsutil ideas
On Thu, Feb 23, 2006 at 8:43 pm, in message [EMAIL PROTECTED], Neil Conway [EMAIL PROTECTED] wrote: Kevin Grittner wrote: Peter Brant, a consultant working with us, has written code which is working for this under both Linux and Windows. [...] For Linux, he used statvfs. statvfs(2) is standardized, but doesn't seem portable: it isn't available on OSX 10.3, NetBSD 2.0 or OpenBSD, for example. Perhaps you can fallback to statfs(2) when it is available? This seems an area where providing consistent cross- platform behavior might be difficult. Do we actually need this functionality inside the DBMS in the first place? It sounds like we should probably just shelve the idea of sharing this code. It is very useful to us, since it allows a single database connection to monitor the health of the database and detect impending failure. Having our monitoring software need to know the operating system of each database, with security to log into the OS of each machine, would be far worse from a security standpoint, more fragile, and more work than adding these functions to the database. But no response so far has indicated any interest in it from any other quarter, and it sounds like the portability issues are more than we want to deal with here. In response to a few other posts -- it is implemented with three functions, which I was bundling to target the contrib level of submission. One function returns a list of volumes (i.e., drive letters in Windows, mount points in Linux), one returns available space for a given volume, and one returns total space for a given volume. Since we have what we need to get our work done, and the community at large doesn't seem interested, I'll shelve the idea of submitting anything. Thanks for the responses. -Kevin ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] fsutil ideas
This seems an area where providing consistent cross- platform behavior might be difficult. Do we actually need this functionality inside the DBMS in the first place? It sounds like we should probably just shelve the idea of sharing this code. It is very useful to us, since it allows a single database connection to monitor the health of the database and detect impending failure. Having our monitoring software need to know the operating system of each database, with security to log into the OS of each machine, would be far worse from a security standpoint, more fragile, and more work than adding these functions to the database. But no Why don't you have a process on the machine update a set of values in the database that you then read from remote? You don't need to know the free diskspace in real time. A 2 minute old value is probably just as good. -- ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] fsutil ideas
Kevin Grittner wrote: Since we have what we need to get our work done, and the community at large doesn't seem interested, I'll shelve the idea of submitting anything. I think you have misinterpreted. By all means share the code. Put it on your website or start a pgfoundry project. Even if it doesn't go into the core code some people might very well be interested to use it. cheers andrew ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] textToQualifiedNameList second parameter
Rafael Martinez Guerrero [EMAIL PROTECTED] writes: Some months ago, the second parameter was removed [1] so I had to modify my program to work after this change. Now with 8.0.7, the second parameter is back again I think you're confused. The second parameter was removed in 8.1. It's present in all prior branches AFAICS. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] User privileges-verification required
Nauman Naeem [EMAIL PROTECTED] writes: I tried the single-user mode option and it worked, thanks! but, don't you people think that we should provide this privilege in multi-user mode as well.In accordence to my second point. No. Restricting what a superuser can do is pointless --- he can always manage to shoot himself in the foot if he tries hard enough. (Consider eg DELETE FROM pg_authid.) Trying to fix it in the reverse direction (re-establishing superuser after the last one's been deleted) has obvious security issues. The problem comes up sufficiently seldom that the single-user-mode backdoor seems sufficient. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] fsutil ideas
On Fri, Feb 24, 2006 at 9:34 am, in message [EMAIL PROTECTED], Rod Taylor [EMAIL PROTECTED] wrote: You don't need to know the free diskspace in real time. A 2 minute old value is probably just as good. Not really, this sort of monitoring has kept us from crashing under our old database product when a poorly written query starts filling available space by populating a temporary table. A green light turns orange (indicating impending failure) on a big board which monitors the health of about 200 servers and about 3000 workstations. A support person drills down through the LED on a version of the big board in their browser, which shows the supporting detail. A runaway query can be identified and killed, protecting the rest of the users. A two minute delay could cause an embarrassing interruption in service for hundreds of our users. Your suggestion would work for the gradual outgrowing of space, but we need to cover both. -Kevin ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Remove ora2pg from contrib
Apparently, the development of ora2pg is going on at http://www.samse.fr/GPL/ora2pg/, and quite actively so, rather than in contrib, so I see no point in keeping it at the latter location except to confuse people. License uniformity is an extra argument for removal. So please speak up or I'll kill it. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Remove ora2pg from contrib
I think we should kill the contrib... I haven't personally seen anyone use it in a long time. I've found that more and more people are using the Java ETL tools (which is kinda sad because ora2pg is pretty good). On 2/24/06, Peter Eisentraut [EMAIL PROTECTED] wrote: Apparently, the development of ora2pg is going on athttp://www.samse.fr/GPL/ora2pg/, and quite actively so, rather than incontrib, so I see no point in keeping it at the latter location except to confuse people.License uniformity is an extra argument for removal.Soplease speak up or I'll kill it.--Peter Eisentrauthttp://developer.postgresql.org/~petere/ ---(end of broadcast)---TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Jonah H. Harris, Database Internals ArchitectEnterpriseDB Corporation732.331.1324
Re: [HACKERS] memory context for tuplesort return values
Simon Riggs [EMAIL PROTECTED] writes: On Thu, 2006-02-23 at 16:10 -0500, Tom Lane wrote: I don't want to give up the idea of keeping sort-local data in a private context --- it just seems cleaner, as well as faster, than letting it be mixed into the caller's stuff. I can see two alternatives: Would that be a single context for all sort operations, or a separate context for each sort within a plan? A private context for each sort operation. Otherwise you lose the point, which is to be able to use MemoryContextDelete to clean up in tuplesort_end. There is some evidence that high sort memory is not that useful during the final merge phase. Would it be possible to have multiple contexts within each sort e.g. Run Forming context and Final Merge context? That would then allow us to more easily free the Run Forming context before moving into the final context with a potentially different size. Possible, but I'm not going to implement it without more evidence. The tests I did way back when showed considerable usefulness for the merge preload behavior, and I think that your change to allow N tapes probably made it even more useful (because with fewer merge passes, the tape files don't get so disorganized). So I'm inclined to leave it as-is. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] fsutil ideas
On Fri, 2006-02-24 at 09:48 -0600, Kevin Grittner wrote: On Fri, Feb 24, 2006 at 9:34 am, in message [EMAIL PROTECTED], Rod Taylor [EMAIL PROTECTED] wrote: You don't need to know the free diskspace in real time. A 2 minute old value is probably just as good. Not really, this sort of monitoring has kept us from crashing under our old database product when a poorly written query starts filling available space by populating a temporary table. A green light turns I see. It is annoying that you cannot easily (takes a patch to PG sources) segregate users temporary workspaces into per-user tablespaces with filesystem quotas. PostgreSQL seems to deal with out of diskspace situations pretty well when it impacts a tablespace (global stuff like WAL or subtransactions have issues -- but they grow slowly) as far as only interrupting service for the individual actions that ran out. You may wish to look at funding toggles that can configure the maximum memory usage and maximum temporary diskspace (different tablespaces with filesystem quotas) on a per user basis similar to the statement_timeout limitations in place today. I'm curious as to how you monitor for total transaction time length to ensure that vacuum is able to do its thing, particularly when the transaction is active (not IDLE). -- ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] fsutil ideas
On Fri, Feb 24, 2006 at 10:57 am, in message [EMAIL PROTECTED], Rod Taylor [EMAIL PROTECTED] wrote: PostgreSQL seems to deal with out of diskspace situations pretty well when it impacts a tablespace (global stuff like WAL or subtransactions have issues -- but they grow slowly) as far as only interrupting service for the individual actions that ran out. We haven't used tablespace features yet, as 3 of the 4 databases running PostgreSQL so far are on Windows. We have run out of space a couple times, and it seems like it handles it well in terms of not corrupting the database, and resuming OK once some space is freed. The messages are not that clear -- some sort of generic I/O write error, as I recall, instead of out of disk space being clearly stated. You may wish to look at funding toggles that can configure the maximum memory usage and maximum temporary diskspace (different tablespaces with filesystem quotas) on a per user basis similar to the statement_timeout limitations in place today. That wouldn't help because the vast majority of the work is done through a middle tier which uses a connection pool shared by all users. It does take some human review and judgment to ensure that a query which is running long and/or using a lot of temp table space is really a problem as opposed to one of our larger legitimate processes. I'm curious as to how you monitor for total transaction time length to ensure that vacuum is able to do its thing, particularly when the transaction is active (not IDLE). We run a database vacuum nightly and review it the next day. (Something will need to be done to automate this with summaries and exception lists when we get more than a few databases on PostgreSQL. We can't have a person reviewing 100 of these every day.) We've not had any nightly vacuum fail to finish. They did start running a tad long until we did some aggressive maintenance at one point. Our autovacuum is configured with fairly aggressive parameters, compared to the default; but, even so, only a few small tables with high update rates normally reach the thresholds. I haven't noticed the autovacuum getting held up on these. -Kevin ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] fsutil ideas
Kevin Grittner [EMAIL PROTECTED] writes: We haven't used tablespace features yet, as 3 of the 4 databases running PostgreSQL so far are on Windows. We have run out of space a couple times, and it seems like it handles it well in terms of not corrupting the database, and resuming OK once some space is freed. The messages are not that clear -- some sort of generic I/O write error, as I recall, instead of out of disk space being clearly stated. Hm, this may be an issue of poor translation of Windows error codes; AFAIR PG is pretty good these days about reporting the correct error message on Unix. Can you dig up the exact message you got, or deliberately reproduce the problem to get a fresh copy? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] fsutil ideas
I'm curious as to how you monitor for total transaction time length to ensure that vacuum is able to do its thing, particularly when the transaction is active (not IDLE). We run a database vacuum nightly and review it the next day. Ahh.. different issues again I guess. I have a few structures that need to be vacuumed every 10 minutes or less. If a transaction runs longer than 20 minutes (thus effectively disabling vacuum for 20 minutes) I run into pretty big problems. I watch for table bloat but I haven't figured out a nice way of tracking down the postgresql process with the oldest transaction running short of patching PostgreSQL to report the XID for a connection in pg_stat_activity. -- ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] fsutil ideas
Rod Taylor [EMAIL PROTECTED] writes: I watch for table bloat but I haven't figured out a nice way of tracking down the postgresql process with the oldest transaction running short of patching PostgreSQL to report the XID for a connection in pg_stat_activity. I don't think you need a patch --- try joining with pg_locks. regards, tom lane ---(end of broadcast)--- TIP 1: 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] fsutil ideas
On Fri, 2006-02-24 at 12:48 -0500, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: I watch for table bloat but I haven't figured out a nice way of tracking down the postgresql process with the oldest transaction running short of patching PostgreSQL to report the XID for a connection in pg_stat_activity. I don't think you need a patch --- try joining with pg_locks. Ugh.. pg_locks is the first think I look at to see if something is blocked that shouldn't be. Don't know why I didn't think of using it for the XID value. Thanks. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] fsutil ideas
On Fri, 2006-02-24 at 19:12, Rod Taylor wrote: On Fri, 2006-02-24 at 12:48 -0500, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: I watch for table bloat but I haven't figured out a nice way of tracking down the postgresql process with the oldest transaction running short of patching PostgreSQL to report the XID for a connection in pg_stat_activity. But I'm afraid that a long running transaction with many short queries will not even show up in pg_stat_activity. So that's not a completely reliable way of catching long running transactions... but it's true that most of the time a long running query is the problem, and that is catchable. Cheers, Csaba. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] fsutil ideas
On Fri, 2006-02-24 at 19:20 +0100, Csaba Nagy wrote: On Fri, 2006-02-24 at 19:12, Rod Taylor wrote: On Fri, 2006-02-24 at 12:48 -0500, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: I watch for table bloat but I haven't figured out a nice way of tracking down the postgresql process with the oldest transaction running short of patching PostgreSQL to report the XID for a connection in pg_stat_activity. But I'm afraid that a long running transaction with many short queries will not even show up in pg_stat_activity. So that's not a completely reliable way of catching long running transactions... but it's true that most of the time a long running query is the problem, and that is catchable. The specific query may not show up but the process should appear in one state or another. That said, pg_locks would still show low XID (compared to the rest) exists and that would probably be the culprit. -- ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] how solve diff of API counstruct_md_array between
Joe Conway wrote: Martijn van Oosterhout wrote: On Thu, Feb 16, 2006 at 08:36:34PM +0100, Pavel Stehule wrote: I use counstruct_md_array function in my Orafunc module. CVS version has diff def now. I am findig way for simple solution of maintaince source code for both version. I have PG_VERSION variable, but it's unusable. Is there way for contrib's autors differentiate PostgreSQL versions? I don't want to have two versions of source code. For my stuff I've generally use CATALOG_VERSION_NO. It's not very easy, but by looking through CVS you can find when the function was created and in your code use: #ifdef CATALOG_VERSION_NO mmddN /* New stuff */ #else /* Old stuff */ #endif I do pretty much the same thing in PL/R. The good news is that CATALOG_VERSION_NO doesn't change for each major release once it is released. The following hasn't been updated since the 8.1 release, but you could use it as a starting point: #if (CATALOG_VERSION_NO = 200211021) #define PG_VERSION_73_COMPAT #elif (CATALOG_VERSION_NO = 200310211) #define PG_VERSION_74_COMPAT #elif (CATALOG_VERSION_NO = 200411041) #define PG_VERSION_80_COMPAT #else #define PG_VERSION_81_COMPAT #endif Yea, that is probably the best you can do currently, but it is pretty ugly. We have PQserverVersion() in libpq for use by clients, which does: conn-sversion = (100 * vmaj + vmin) * 100 + vrev; Perhaps we should have a function in the server that has this. PG_VERSION isn't easy to use because it is a string, and changes during minor versions. initdb.c uses get_short_version() to trims PG_VERSION to the major part. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] fsutil ideas
Ühel kenal päeval, R, 2006-02-24 kell 19:20, kirjutas Csaba Nagy: On Fri, 2006-02-24 at 19:12, Rod Taylor wrote: On Fri, 2006-02-24 at 12:48 -0500, Tom Lane wrote: Rod Taylor [EMAIL PROTECTED] writes: I watch for table bloat but I haven't figured out a nice way of tracking down the postgresql process with the oldest transaction running short of patching PostgreSQL to report the XID for a connection in pg_stat_activity. But I'm afraid that a long running transaction with many short queries will not even show up in pg_stat_activity. It will show as IDLE in transaction The harder part would be knowing how long the queri has been running in wallclock time, not in transactions. --- Hannu ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] how solve diff of API counstruct_md_array between
On Fri, Feb 24, 2006 at 02:57:19PM -0500, Bruce Momjian wrote: Yea, that is probably the best you can do currently, but it is pretty ugly. We have PQserverVersion() in libpq for use by clients, which does: conn-sversion = (100 * vmaj + vmin) * 100 + vrev; Perhaps we should have a function in the server that has this. PG_VERSION isn't easy to use because it is a string, and changes during minor versions. We don't need a function to do it, because none of that can be used by a compiler. If a structure gains or loses a member, the only way you can do it portibly is if the compiler can determine which version to use. The only thing the preprocessor can use is: - Is a (preprocessor) symbol defined - Is it numerically greater equal or less than another number So the only solution would be something like: #define POSTGRESQL_MAJOR 8 #define POSTGRESQL_MINOR 1 #define POSTGRESQL_RELEASE 1 Or #define POSTGRESQL_VERSION 80101 Maybe something to indicate beta or CVS. Anything else is not likely to be an improvement on what we have now. Besides, adding stuff now is not terribly useful since people want to support back to 7.3/7.4 and until a new scheme is old enough that 8.2 is ancient (first release it could possibly appear in) it won't get a lot of usage. Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. signature.asc Description: Digital signature
Re: [HACKERS] Blog post on EnterpriseDB...maybe off topic
Folks, What they don't say is whether that is a 50% speed up from the default settings or a 50% increase from a carefully hand tunes file. AFAIT, most of their performance speed-up comes from two sources: 1) a carefully hand-tuned compile of Postgres using ICC, and 2) Improving on the default postgres.conf params. BTW, they have set up 3 pgfoundry projects to contribute some-but-not-all of their improvements to the community, and have actively sought feedback from me, Bruce, Simon and others on how and what to contribute. They also paid for Alvaro's work on shared locks. So if that code has been slow in coming, that's due to their staff being overcommitted (it's a start-up). -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Remove ora2pg from contrib
On Friday 24 February 2006 11:31, Peter Eisentraut wrote:
Apparently, the development of ora2pg is going on at
http://www.samse.fr/GPL/ora2pg/, and quite actively so, rather than in
contrib, so I see no point in keeping it at the latter location except to
confuse people. License uniformity is an extra argument for removal. So
please speak up or I'll kill it.
Please kill it already. This has been discussed and agreed upon a number of
times before, the last of which I even sent a quasi-patch to remove this
particular entry.
http://archives.postgresql.org/pgsql-hackers/2005-12/msg01213.php
Incidentally my offer from that email still stands if you guys are interested.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 1: 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] Remove ora2pg from contrib
Robert, Please kill it already. This has been discussed and agreed upon a number of times before, the last of which I even sent a quasi-patch to remove this particular entry. Actually, there are 4-6 more projects slated to get removed from contrib per decision on this list; they're waiting for me to prepare a home for them on pgFoundry. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] fsutil ideas
Oh, so does it actually involve any server modifications? Or can it just go into pgfoundry? On Fri, Feb 24, 2006 at 08:25:03AM -0600, Peter Brant wrote: The code in question is written as C extension functions. I think we were thinking it might be something for contrib (although perhaps that would be too much of an official blessing too?) Pete Jim C. Nasby [EMAIL PROTECTED] 02/24/06 8:04 am Isn't this something that could be accomplished entirely within a function? I suppose it might have to be an untrusted language, but that still seems cleaner than putting it in the backend. Plus, ISTM that something like perl is more likely to have a cross-platform means of accomplishing this. -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.comwork: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] fsutil ideas
On Fri, Feb 24, 2006 at 5:00 pm, in message [EMAIL PROTECTED], Jim C. Nasby [EMAIL PROTECTED] wrote: Oh, so does it actually involve any server modifications? Or can it just go into pgfoundry? No server modifications. I've got it bundled up as though it were going to be under contrib, and I've applied for a pgfoundry project for it. Waiting for approval. I've not dealt with pgfoundry before, so I don't know how much modification, if any, is needed to set that up. It's working for us now by building in standard contrib fashion (from contrib/fsutil). The files: -rw-r--r-- 1 kgrittn users 318 Feb 24 11:39 Makefile -rw-r--r-- 1 kgrittn users 751 Feb 24 11:44 README.fsutil -rw-r--r-- 1 kgrittn users 7857 Feb 24 14:25 fsutil.c -rw-r--r-- 1 kgrittn users 2149 Feb 24 14:25 fsutil.h -rw-r--r-- 1 kgrittn users 440 Feb 24 12:54 fsutil.sql.in Any pointers on setting up the project, or a URL to a page on that topic, would be welcome. I haven't stumbled across it yet; although, once I know about it I'm sure it will seem obvious. -Kevin ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] fsutil ideas
Kevin Grittner wrote: I've not dealt with pgfoundry before, so I don't know how much modification, if any, is needed to set that up. It's working for us now by building in standard contrib fashion (from contrib/fsutil). The files: Having it build with PGXS would be a definite plus for ease of installation. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 1: 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] fsutil ideas
On Fri, Feb 24, 2006 at 5:25 pm, in message [EMAIL PROTECTED], Alvaro Herrera [EMAIL PROTECTED] wrote: Having it build with PGXS would be a definite plus for ease of installation. It does. ---(end of broadcast)--- TIP 1: 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] Remove ora2pg from contrib
Josh Berkus josh@agliodbs.com writes: Please kill it already. This has been discussed and agreed upon a number of times before, the last of which I even sent a quasi-patch to remove this particular entry. Actually, there are 4-6 more projects slated to get removed from contrib per decision on this list; they're waiting for me to prepare a home for them on pgFoundry. Right. The new information in this thread is that ora2pg should not go to pgFoundry because it's already got a home elsewhere. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] Remove ora2pg from contrib
On Friday 24 February 2006 18:37, Tom Lane wrote:
Josh Berkus josh@agliodbs.com writes:
Please kill it already. This has been discussed and agreed upon a number
of times before, the last of which I even sent a quasi-patch to remove
this particular entry.
Actually, there are 4-6 more projects slated to get removed from contrib
per decision on this list; they're waiting for me to prepare a home for
them on pgFoundry.
Right. The new information in this thread is that ora2pg should not go
to pgFoundry because it's already got a home elsewhere.
That's not new, see the link I posted. It's just waiting on Josh or for the
task to be delegated.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
[HACKERS] constraints and sql92 information_schema compliance
Hello all. I've got a question with regard to the INFORMATION_SCHEMA of PostgreSQL, specificially related to constraints. In the SQL92 specification, the DEFINITION_SCHEMA.DOMAIN_CONSTRAINTS (the imaginary base for INFORMATION_SCHEMA.DOMAIN_CONSTRAINTS), has a primary key: CONSTRAINT_CATALOG, CONSTRAINT_SCHEMA, CONSTRAINT_NAME This would leave me to believe that at constraints must have a unique name within a given schema; however, this seems not to be the case: # create domain test_one text - constraint test check (value is not null); CREATE DOMAIN # create domain test_two text - constraint test check (value is not null); CREATE DOMAIN # select constraint_catalog, constraint_schema, constraint_name - from information_schema.domain_constraints - where domain_name like 'test_%'; constraint_catalog | constraint_schema | constraint_name +---+- cce| public| test cce| public| test (2 rows) So it would seem that naming rules for constraints in PostgreSQL isn't exactly compliant with SQL92. I'm curious what sorts of constraints are enforced... Thank you so much, Clark ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] constraints and sql92 information_schema compliance
Clark, So it would seem that naming rules for constraints in PostgreSQL isn't exactly compliant with SQL92. I'm curious what sorts of constraints are enforced... Correct. Our uniqueness on constraints is: schema_name | table_name | constraint_name We're aware that it's a violation of SQL92, but there's no way for us to change it now without making it very hard for people to upgrade. And, frankly, aside from the very occasional information_schema complaint, nobody seems to care. -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 1: 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] constraints and sql92 information_schema compliance
On Fri, Feb 24, 2006 at 04:23:19PM -0800, Josh Berkus wrote: | Correct. Our uniqueness on constraints is: | schema_name | table_name | constraint_name | | We're aware that it's a violation of SQL92, but there's no way for us to | change it now without making it very hard for people to upgrade. And, | frankly, aside from the very occasional information_schema complaint, | nobody seems to care. Thank you for the quick response; I'm sure you've considered contatinating the internal pg_type name with the pg_constraint name? If so, is there areason this was rejected, since it is a constraint it isn't like you'd reference it in an SQL query (just trying to figure out what I should do in my application). On a related note, this view seems to be filtering by user, I'm curious what the rule is (I'm not that familiar /w PostgreSQL's internal meta-model)? While the textual description of this view Identify domain constraints in this catalog accessable to a given user. has not changed between SQL-1992 and SQL-2003, the actual critera specified is quite different: In SQL 1992, it seems to show only domains that are in schemas owned by the current user. In SQL 2003, it seems to be more intelligent: showing all constraints that are visible to the current user. I'm curious which rule PostgreSQL's information_schema is using? I think the SQL-2003 rules more properly follow the textual description and are more useful; the SQL-1999 rules are effectively useless in all but trivial cases. Kind Regards, Clark ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_service.conf
Mark Woodward wrote: It turns out what you like actually exists, lookup the service parameter in the connectdb string. It will read the values for the server, port, etc from a pg_service.conf file. There is an example in the tree but it looks something like the following: [servicename] dbname=blah user=blah pass=blah So all you need to specify is service=servicename and it will grab the parameters. This allows you to change the connection without changeing the code. This is a great feature!! It doesn't seem to be documented in the administrators guide. Its mentioned in the libpq section, and only a reference to pg_service.conf.sample IMHO we should push for this to be the mainstream connection methodology!!! The variables: host, port, and dbname are very problematic for admins and developers who often live in different worlds. The documenation is sparse because at the time it was added, there was little interest in it from the community, so a single mention was added and documentation was pushed into the config file. We can adjust that now that there is interest. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 1: 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] AC_REPLACE_FUNCS([getaddrinfo]) in 8.1.3
Tom Lane wrote: Albert Chin [EMAIL PROTECTED] writes: On Sun, Feb 19, 2006 at 09:56:20PM -0500, Tom Lane wrote: Hmm, where is it then? getaddrinfo is a macro in netdb.h: Yes, we know that. The question was where does the macro point. The solution is to either revert to the 8.1.1 code (my recommendation) or check for ngetaddrinfo. The latter is a crude hack though. Hm, I think both of us are confused: me because I thought we'd changed the getaddrinfo test, which in fact has not happened, and you because you think 8.1.1 is different from 8.1.3 on this point, which it is not. Would you try the patch proposed at http://archives.postgresql.org/pgsql-patches/2006-01/msg00299.php and see if it fixes the problem? That patch has *not* gotten applied, probably because no one confirmed that it worked. Correct, the patch was still my personal patch directory awaiting feedback. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Resurrecting some old patches
Aren't they in the 8.2 hold queue that I have not processed yet: http://momjian.postgresql.org/cgi-bin/pgpatches_hold --- Martijn van Oosterhout wrote: -- Start of PGP signed section. Hi, Late last year I posted some patches for psql but they were deferred pending the release of 8.2. However, they are not in the patch queue so I thought I'd bring them up again now the release is done. 1. Dealing with a buggy readline on some platforms w.r.t. --as-needed. The serious arguments for --as-needed have gone now we exclude various libs from the main postgres binary. However, the other executables still include a lot more libs than necessary. http://archives.postgresql.org/pgsql-hackers/2005-10/msg01364.php 2. Handling Ctrl-C pressed while running an external pager. This bug still irritates me from time to time so it would be nice to fix it for once and for all. Not to meantion the memory and file descriptor leaks caused by the current code. However, the tree has deviated significantly since that patch was posted. I have prepared a version against HEAD if people are still interested. The details are in this message: http://archives.postgresql.org/pgsql-patches/2005-10/msg00194.php The only change from that is that I've now also removed paging support from the following programs: createdb, createlang, createuser, dropdb, droplang, dropuser, clusterdb, vacuumdb, reindexdb. In so far as it's not clear how much they used the paging support anyway, keeping it would require setting up of the signal handlers the same way psql does since the code is shared. I figured it wasn't worth it. The new patch is here but can be posted to -patches if there is sufficient interest: http://svana.org/kleptog/pgsql/psql-ctrlc2.patch Have a nice day, -- Martijn van Oosterhout kleptog@svana.org http://svana.org/kleptog/ Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a tool for doing 5% of the work and then sitting around waiting for someone else to do the other 95% so you can sue them. -- End of PGP section, PGP failed! -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] pg_config, pg_service.conf, postgresql.conf ....
Mark Woodward wrote: If you require a policy, then YOU are free to choose the policy that YOU need. You're not forced to accept other peoples' policies that may conflict with things in your environment. The problem is that there is no mechanism through which one can implement policy. You are left to roll your own each and every time. A mechanism provided, but not enforced, by postgresql would go a LONG way toward enabling a coherent policy. Unless you can have +80% of sites using the default, it isn't worth it and is more confusing than if you had never created it at all. What is wrong with defining an environment variable in /etc/profile? -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
[HACKERS] Pl/Python -- current maintainer?
I'm interested in poking though and taking a shot at getting my feet wet with pl/python. I see the file is copyright Andrew Bosma -- is he still around perhance? Is anyone currently the 'owner' ? James Robinson Socialserve.com ---(end of broadcast)--- TIP 1: 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] Pl/Python -- current maintainer?
James Robinson wrote: I'm interested in poking though and taking a shot at getting my feet wet with pl/python. I see the file is copyright Andrew Bosma -- is he still around perhance? Is anyone currently the 'owner' ? To my knowledge there is no current maintainer of plPython and it definitely needs some love. James Robinson Socialserve.com ---(end of broadcast)--- TIP 1: 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 -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Pl/Python -- current maintainer?
I see neilc has hacked on it very recently to reduce memory leaks. I take that as both good and bad signs. We're a [ small ] python shop, and would be most interested in being able to simplify our life through doing some things in plpython instead of pl/pgsql where appropriate. Keeping our constants and so forth in the appropriate python module would make things ever so much simpler here and there at the very least. But we've never hacked on the backend, nor at the C python API level. But I see no reason why not to start now -- lurked here for many a year. For example, I see that plpython functions cannot be declared to return void. That can't be too tough to remedy. Implementing the DBI 2.0 API interface to SPI can wait another day. On Feb 24, 2006, at 11:08 PM, Joshua D. Drake wrote: James Robinson wrote: I'm interested in poking though and taking a shot at getting my feet wet with pl/python. I see the file is copyright Andrew Bosma -- is he still around perhance? Is anyone currently the 'owner' ? To my knowledge there is no current maintainer of plPython and it definitely needs some love. James Robinson Socialserve.com ---(end of broadcast)--- TIP 1: 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 -- The PostgreSQL Company - Command Prompt, Inc. 1.503.667.4564 PostgreSQL Replication, Consulting, Custom Development, 24x7 support Managed Services, Shared and Dedicated Hosting Co-Authors: PLphp, PLperl - http://www.commandprompt.com/ James Robinson Socialserve.com ---(end of broadcast)--- TIP 1: 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] Remove ora2pg from contrib
Great, please remove it. Also, please mention the new URL so I can put it in the release notes. Thanks. --- Peter Eisentraut wrote: Apparently, the development of ora2pg is going on at http://www.samse.fr/GPL/ora2pg/, and quite actively so, rather than in contrib, so I see no point in keeping it at the latter location except to confuse people. License uniformity is an extra argument for removal. So please speak up or I'll kill it. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
[HACKERS] Back from Japan
I am back from Japan, and have caught up on email in a single 18 hour day (100 emails/hour average). I will return to process emails needing special attention in the next few days, and start applying more patches soon. -- Bruce Momjian http://candle.pha.pa.us SRA OSS, Inc. http://www.sraoss.com + If your life is a hard drive, Christ can be your backup. + ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
