[HACKERS] postgresql.conf basic analysis tool
Is there any interest in a basic perl script that would read through a postgresql.conf file and calculate approximate memory (and shared memory) usage? Also, are there any other (simple for now) things I should look at in the process? Asking because I'm getting annoyed with doing this by hand so... Drew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
Thomas Hallgren wrote: Joshua D. Drake wrote: What happens when the FSF inevitably removes the license clause and makes it pure GPL? I'm sorry but I don't follow. You're saying that it's inevitable that FSF will remove the 'libgcc' exception from libgcj? Why on earth would they do that? My guess is that it will go the other way (i.e. LGPL). What's the logic in having different licenses on libg++ and libgcj? You are trying to apply logic to what is a political organization. Keep in mind that LGPL stands for LESSOR GPL. RMS would prefer that ALL licenses be under the GPL (or something very similar) that does not allow anyone to close source the software. This isn't really the point of the thread though. Sincerely, Joshua D. Drake Now all of this being said, I doubt there is actually an issue here because: It doesn't HAVE TO BE BUILT, it is not a derivative product. Well, assume that FSF indeed did remove the exception. It would take me 30 minutes or so to create a substitute BSD licensed dummy JNI library with associated headers that would allow PL/Java to be built without any external modules at all. It's then completely up to the user what he/she wants to slot in as a replacement. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 6: explain analyze is your friend -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
Joshua D. Drake wrote: Well, assume that FSF indeed did remove the exception. It would take me 30 minutes or so to create a substitute BSD licensed dummy JNI library with associated headers that would allow PL/Java to be built without any external modules at all. It's then completely up to the user what he/she wants to slot in as a replacement. Do we want to do that? I mean (and I am not saying it is, I am asking) is that a bit grey? I would prefer it be black and white. The JNI API is an open standard so I have every right to create a BSD licensed dummy for it. The user may choose a JVM from IBM, Sun, BEA, or other (like GCJ) to run. That's the essence of having a standardized API. What can possibly be 'grey' about that? Regards, Thomas Hallgren ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] [patch 0/9] annual pgcrypto update
Neil Conway <[EMAIL PROTECTED]> writes: > On Tue, 2006-07-11 at 15:57 -0400, Marko Kreen wrote: >> Few cleanups and couple of new things [...] > Applied, thanks for the patch. This has broken two out of the four buildfarm members that reported in the last half hour :-( I think kudu does not like // comments, not sure what kookaburra is on about. regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Three weeks left until feature freeze
Well, assume that FSF indeed did remove the exception. It would take me 30 minutes or so to create a substitute BSD licensed dummy JNI library with associated headers that would allow PL/Java to be built without any external modules at all. It's then completely up to the user what he/she wants to slot in as a replacement. Do we want to do that? I mean (and I am not saying it is, I am asking) is that a bit grey? I would prefer it be black and white. Are their JVMs that are BSD compatible? It is my understanding that you can ship Java (I could be completely on crack here) in a closed source product without issue right? If so... then wouldn't our argument be to strongly suggest that they use the Sun JVM (or IBM if that is relevant?). Sincerely, Joshua D. Drake Regards, Thomas Hallgren -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [PATCHES] [patch 0/9] annual pgcrypto update
On Thu, 2006-07-13 at 00:50 -0400, Tom Lane wrote: > This has broken two out of the four buildfarm members that reported > in the last half hour :-( I think kudu does not like // comments, > not sure what kookaburra is on about. BTW, you've switched your animal names :) I fixed the C++-style comment. Marko, can you take a look at what is causing this regression test failure? The failing machine is kudu: http://www.pgbuildfarm.org/cgi-bin/show_history.pl?nm=kudu&br=HEAD The regression.diffs are: *** ./expected/pgp-pubkey-decrypt.out Wed Jul 12 21:30:59 2006 --- ./results/pgp-pubkey-decrypt.outWed Jul 12 21:39:15 2006 *** *** 544,555 -- password-protected secret key, wrong password select pgp_pub_decrypt(dearmor(data), dearmor(seckey), 'foo') from keytbl, encdata where keytbl.id=5 and encdata.id=1; ! ERROR: Corrupt data -- password-protected secret key, right password select pgp_pub_decrypt(dearmor(data), dearmor(seckey), 'parool') from keytbl, encdata where keytbl.id=5 and encdata.id=1; ! pgp_pub_decrypt ! - ! Secret msg ! (1 row) ! --- 544,551 -- password-protected secret key, wrong password select pgp_pub_decrypt(dearmor(data), dearmor(seckey), 'foo') from keytbl, encdata where keytbl.id=5 and encdata.id=1; ! ERROR: Unsupported cipher algorithm -- password-protected secret key, right password select pgp_pub_decrypt(dearmor(data), dearmor(seckey), 'parool') from keytbl, encdata where keytbl.id=5 and encdata.id=1; ! ERROR: Unsupported cipher algorithm -Neil ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Online index builds
Simon Riggs <[EMAIL PROTECTED]> writes: > On Wed, 2006-07-12 at 12:09 -0400, Greg Stark wrote: > > no regression tests yet. > > We'll need some performance tests that show that lock-hold time is > *actually* reduced, given the shenanigans needed to get there. I'm not sure what you mean by "lock-hold time". Online index builds effectively take *no* locks in the user-visible sense that regular index builds do. Other transactions can insert, update, delete continuously throughout the entire process. The only locks that are taken are 1) a ShareUpdateExclusiveLock which blocks vacuum from running on the table being indexed. This is taken by both phase 1 and phase 2. (Actually I had the wrong lock in the patch I emailed in one place. Fixed in my source tree here) 2) An ExclusiveLock that is taken momentarily and immediately released. Even if that can never be acquired due to a busy system it can eventually proceed anyways as long as there are no long-running transactions that are refusing to commit. That said we do need some performance tests to get an idea how long phase 2 takes for large tables. The additional index and heap scan and tid sort could take a substantial amount of time though never as long as the original index build done in phase 1. What's worse is that in some cases the merge could potentially be doing a lot of retail index inserts. I have no good intuition for how long those will take relative to the wholesale index build method, especially since for some index methods like GIN retail inserts are extremely expensive. So for indexes that don't have a lot of records that need to be inserted individually what I expect -- and what I put in the docs -- is something under 100% time penalty for an online index build. In fact I expect it to be more like 50% though it depends on how wide the original index. For ones that do have lots of records mutated for phase 2 all bets are off. > We may need to have usage recommendations in the docs. I'm writing docs now. I'm trying to find a happy medium between explaining all the issues and spamming the docs with lots of discussion. Right now what I have is a single paragraph in the create_index man page that refers to the Postgres manual where I list the issues in more depth. I also still have to get some kind of regression tests. I don't think we have any concurrent regression tests currently, do we? To thoroughly test it will be quite hard. Some of the corner cases are extremely narrow or require very particular types of transactions running with very specific timing. -- greg ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
Josh Berkus wrote: Thomas, I'm starting to have second thoughts about this suggestion. I was enthusiastic about it at the summit, but I was unaware of the sheer size of PL/Java. 38,000 lines of code is 8% of the total size of Postgresql ... for *one* PL. Dave Cramer acquainted me with some of the difficulties of doing a Java PL today, and I understand why it needs to be that large. However, 38,000 lines of code -- much of it in a non-C language -- presents a possible debugging/maintenance major headache, especially if you someday left the project for some reason. OK. You're the one that suggested this submission attempt. There's not much point in pursuing it if you have second thoughts. > Maybe we do need to look at a plug-in build tool, instead. > Right, something that would allow PL/Java to participate in a build farm. That would be cool and also resolve a some of the issues. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
Joshua D. Drake wrote: What happens when the FSF inevitably removes the license clause and makes it pure GPL? I'm sorry but I don't follow. You're saying that it's inevitable that FSF will remove the 'libgcc' exception from libgcj? Why on earth would they do that? My guess is that it will go the other way (i.e. LGPL). What's the logic in having different licenses on libg++ and libgcj? Now all of this being said, I doubt there is actually an issue here because: It doesn't HAVE TO BE BUILT, it is not a derivative product. Well, assume that FSF indeed did remove the exception. It would take me 30 minutes or so to create a substitute BSD licensed dummy JNI library with associated headers that would allow PL/Java to be built without any external modules at all. It's then completely up to the user what he/she wants to slot in as a replacement. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
Tom Lane wrote: Thomas Hallgren <[EMAIL PROTECTED]> writes: Why to you persist talking about licensing issues with PL/Java? There are none. PL/Java builds and runs just fine with gcj and the above statement is completely false. Um ... if you use it with gcj, there may or may not be any licensing problems (please recall we are trying to be a BSD-only project, not a BSD-and-LGPL project), You have no problems using gcc, gnu-make, etc. What's the difference? but what of people who use some other JVM? It's not like gcj works for everyone yet. What of them? If they decide to use another JVM, well, then let them. I don't see where that becomes a licensing problem from PostgreSQL. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
Thomas Hallgren <[EMAIL PROTECTED]> writes: > Why to you persist talking about licensing issues with PL/Java? There are > none. PL/Java > builds and runs just fine with gcj and the above statement is completely > false. Um ... if you use it with gcj, there may or may not be any licensing problems (please recall we are trying to be a BSD-only project, not a BSD-and-LGPL project), but what of people who use some other JVM? It's not like gcj works for everyone yet. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
Thomas Hallgren wrote: Tom Lane wrote: Thomas Hallgren <[EMAIL PROTECTED]> writes: Why to you persist talking about licensing issues with PL/Java? There are none. PL/Java builds and runs just fine with gcj and the above statement is completely false. Um ... if you use it with gcj, there may or may not be any licensing problems (please recall we are trying to be a BSD-only project, not a BSD-and-LGPL project), You have no problems using gcc, gnu-make, etc. What's the difference? Well there is a couple of literal differences. gcc, gnu-make are irrelevant. What is relevant is libc which is LGPL. Gcj IS GPL, not LGPL :( it just has an exception clause Keep in mind that that there are all kinds of oddities when mixing licenses. Is Sun's JVM GPL compatible? If not, the plJava can't use it. What happens when the FSF inevitably removes the license clause and makes it pure GPL? Now all of this being said, I doubt there is actually an issue here because: It doesn't HAVE TO BE BUILT, it is not a derivative product. It doesn't ship with the JVM which means it is up to the user to break the license not the PostgreSQL project... However that last one is bad mojo :( Sincerely, Joshua D. Drake but what of people who use some other JVM? It's not like gcj works for everyone yet. What of them? If they decide to use another JVM, well, then let them. I don't see where that becomes a licensing problem from PostgreSQL. Regards, Thomas Hallgren -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
Josh Berkus wrote: Perhaps it's no surprise that I disagree when you say PL/J could be considered in the same light as PL/Java. Then again, I'm fairly biased ;-) This attitude does you no credit, Thomas. My diplomatic skills are somewhat limited :-) I might be blunt at times. I'm sure there are other more subtle ways to get the message through. I'm trying to be honest and up-front. IMO, that should count for something. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
Tom, Perhaps more, because it gives us an extra layer of insulation from JVM licensing questions. I really don't see licensing issues as being relevant. Your other concern certainly is, though. --Josh ---(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] Three weeks left until feature freeze
Thomas, I'm starting to have second thoughts about this suggestion. I was enthusiastic about it at the summit, but I was unaware of the sheer size of PL/Java. 38,000 lines of code is 8% of the total size of Postgresql ... for *one* PL. Dave Cramer acquainted me with some of the difficulties of doing a Java PL today, and I understand why it needs to be that large. However, 38,000 lines of code -- much of it in a non-C language -- presents a possible debugging/maintenance major headache, especially if you someday left the project for some reason. Maybe we do need to look at a plug-in build tool, instead. Perhaps it's no surprise that I disagree when you say PL/J could be considered in the same light as PL/Java. Then again, I'm fairly biased ;-) This attitude does you no credit, Thomas. --Josh Berkus ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
Thomas Hallgren wrote: Tom Lane wrote: ... equal claim to inclusion in core. Perhaps more, because it gives us an extra layer of insulation from JVM licensing questions. Tom, Why to you persist talking about licensing issues with PL/Java? There are none. PL/Java builds and runs just fine with gcj and the above statement is completely false. Just to further this with actual documentation :) 1.1 What license is used for libgcj? libgcj is distributed under the GPL, with the 'libgcc exception'. This means that linking with libgcj does not by itself cause your program to fall under the GPL. See LIBGCJ_LICENSE in the source tree for more details. Sincerely, Joshua D. Drake Dave, What JVM requirements does PL/J currently have? What license implications are imposed by the components that it depends upon? Regards, Thomas Hallgren -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
Tom Lane wrote: ... equal claim to inclusion in core. Perhaps more, because it gives us an extra layer of insulation from JVM licensing questions. Tom, Why to you persist talking about licensing issues with PL/Java? There are none. PL/Java builds and runs just fine with gcj and the above statement is completely false. Dave, What JVM requirements does PL/J currently have? What license implications are imposed by the components that it depends upon? Regards, Thomas Hallgren ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Three weeks left until feature freeze
Dave Cramer wrote: I expect to see a new release shortly. Dave, I tried to obtain the source but whenever I try I get: [thhal]$ cvs -d :pserver:[EMAIL PROTECTED]:/home/projects/plj/scm login Logging in to :pserver:[EMAIL PROTECTED]:2401/home/projects/plj/scm CVS password: /home/projects/plj/scm: no such repository I can browse the source using the web interface though. Judging from that, there's been no CVS activity since I last tried, i.e. august last year. Is the source being maintained somewhere else? How do I obtain the latest CVS? Judging from your statement a lot must have happened that would be interesting to look at. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pre_load_libraries
Marc Munro <[EMAIL PROTECTED]> writes: > ... A better solution from my point of view would be > to simply move the call to process_preload_libraries to a point after > shared memory has been set up. Is there some reason this could not be > done? That would make it impossible for a preloaded library to request any shared memory of its own --- something that admittedly we don't have a hook to support, but do we want to foreclose it permanently? regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
On 12-Jul-06, at 10:44 PM, Tom Lane wrote: "Jonah H. Harris" <[EMAIL PROTECTED]> writes: On 7/12/06, David Fetter <[EMAIL PROTECTED]> wrote: Are they mutually exclusive? I can imagine, at least for development purposes, that someone might want to install both. I believe both can be installed and running at the same time. I don't really think anyone would want to run both, but that's just my opinion. On what grounds do you not think that? PL/J uses an external JVM, PL/Java one that is running in the backend process. (Or maybe it was the other way 'round, I'm too tired to remember tonight.) That's a really fundamental difference that makes them suited for very different applications; not to mention the resulting different licensing scenarios. No, this is correct. The points that have been made in this thread about PL/J not being actively maintained are important, but other than that objection, I expect to see a new release shortly. I can see no reason that PL/J wouldn't have an equal claim to inclusion in core. Perhaps more, because it gives us an extra layer of insulation from JVM licensing questions. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Online index builds
Simon Riggs <[EMAIL PROTECTED]> writes: > On Wed, 2006-07-12 at 12:09 -0400, Greg Stark wrote: >> no regression tests yet. > We'll need some performance tests that show that lock-hold time is > *actually* reduced, given the shenanigans needed to get there. Reducing lock hold time is not the point ... reducing the strength of the lock at the cost of increased elapsed time is the point. > We may need to have usage recommendations in the docs. Agreed. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
"Jonah H. Harris" <[EMAIL PROTECTED]> writes: > On 7/12/06, David Fetter <[EMAIL PROTECTED]> wrote: >> Are they mutually exclusive? I can imagine, at least for development >> purposes, that someone might want to install both. > I believe both can be installed and running at the same time. I don't > really think anyone would want to run both, but that's just my > opinion. On what grounds do you not think that? PL/J uses an external JVM, PL/Java one that is running in the backend process. (Or maybe it was the other way 'round, I'm too tired to remember tonight.) That's a really fundamental difference that makes them suited for very different applications; not to mention the resulting different licensing scenarios. The points that have been made in this thread about PL/J not being actively maintained are important, but other than that objection, I can see no reason that PL/J wouldn't have an equal claim to inclusion in core. Perhaps more, because it gives us an extra layer of insulation from JVM licensing questions. 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] Implied Functional Index use
Simon Riggs <[EMAIL PROTECTED]> writes: > Normally, I would not suggest that we do things only for certain data > types only. In this case however, it seems that the reason it would work > only for INTEGER and TEXT data types is that they are simple atomic > datatypes that have the required properties. So doing this for those > datatypes only seems permissable on a theoretical basis, rather than > just because we can't be bothered to do it for more complex types. There's nothing simple nor atomic about TEXT, and in fact until very recently text_eq was NOT true equality by this definition. See discussions about hu_HU locale back in December. A number of people thought that fix was an ugly kluge, and so we may someday go back to a behavior in which text_eq is again not true equality --- in particular I'm dubious that such a restriction can survive once we support multiple encodings/collations in the same database. More generally, I don't believe in hacks that only work for a small number of built-in types: to me, that's prima facie evidence that you haven't thought the problem through. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] pgsql-patches considered harmful
On Wed, 12 Jul 2006, Magnus Hagander wrote: There are list servers out there capable of simply ripping any attachments to a message (possibly over a certain size) and stick it on a website, replacing it with a link in the email. Is majordomo one of them? Majordomo2 has a 'hook' for it, but, like most OSS software, nobody has had the requirement to actually code it ... any perl experts here interested in doing it? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(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] speed checks ...
ignore ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email . [EMAIL PROTECTED] MSN . [EMAIL PROTECTED] Yahoo . yscrappy Skype: hub.orgICQ . 7615664 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Updateable views for 8.2 or 8.3?
On 7/12/06, Joe Conway <[EMAIL PROTECTED]> wrote: Jaime Casanova wrote: > > is anybody working on the Bernd Helmle's updateable views patch? or > know what the status of this is? I was just wondering about this also. If no one else is working on it, I'd like to try to push it through to completion for 8.2 myself. Can anyone summarize what the open issues are? Joe if nobody step up i can do the list. i think this is the last patch that he post: http://archives.postgresql.org/pgsql-hackers/2006-03/msg00586.php i will try to rebuild a test script have made for this... -- regards, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] postgresql.conf basic analysis tool
"Andrew Hammond" <[EMAIL PROTECTED]> wrote > Also, are there any other (simple for now) things I > should look at in the process? > The shared memory estimiation logic is in ipc/ipci.c/CreateSharedMemoryAndSemaphores(). If you want to get an accurate number, you need to consider: (1) different PostgreSQL versions; (2) if EXEC_BACKEND is defined; (3) other defines like BLCKSZ, NUM_SLRU_BUFFERS, etc. So a better way IMHO is not to use perl script -- you have to reinvent the shmem estimation logic. You can put the logic in a separate function in backend and export it. Regards, Qingqing ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pre_load_libraries
On Wed, 2006-07-12 at 02:18 -0300, I wrote: > I am trying to create an initialisation function that is called using > the preload_libraries option. > > The purpose of this is to set up shared memory for Veil, independant > of postgres' own shared memory. Simple init functions work fine, but > as soon as I place calls to ShemAlloc, or LWLockAssign, the server > startup simply halts. To answer my own question, yes I am being unreasonable. Shared memory has not been set up at the time that process_preload_libraries is called. Since lwlocks are allocated from postgres shared memory, I cannot assign an lwlock from Veil's initialisation code. Instead, I can make the allocation of the lwlock the responsibility of the first session that uses a Veil function but I need a lock to prevent a race. My current thinking is to simply subvert one of the existing lwlocks while I assign my own. A better solution from my point of view would be to simply move the call to process_preload_libraries to a point after shared memory has been set up. Is there some reason this could not be done? On a related note, I can see no way to release Veil's shared memory segment when postgres is shut down. Perhaps I should be thinking about making the management of such shared memory segments something that postgres does on behalf of its add-ins, though that seems presumptious. I'd appreciate any suggestions, pointers, random thoughts, etc. __ Marc signature.asc Description: This is a digitally signed message part
Re: [HACKERS] lastval exposes information that currval does not
Phil Frost wrote: > On Wed, Jul 12, 2006 at 11:37:37AM -0400, Bruce Momjian wrote: > > > > Updated text: > > > >For schemas, allows access to objects contained in the specified > >schema (assuming that the objects' own privilege requirements are > >also met). Essentially this allows the grantee to look up > >objects within the schema. Without this permission, it is still > >possible to see the object names by querying the system tables, but > >they cannot be accessed via SQL. > > No, this still misses the point entirely. See all my examples in this > thread for ways I have accessed objects without usage to their schema > with SQL. OK, well we are not putting a huge paragraph in there. Please suggest updated text. -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.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
Re: [HACKERS] Implied Functional Index use
On Tue, 2006-07-11 at 17:31 -0400, Tom Lane wrote: > Simon Riggs <[EMAIL PROTECTED]> writes: > > ... > > - add a new boolean to pg_operator to allow us to define which operators > > offer true equality > > ... > > This would be useful for other purposes too, as we keep coming up > against "what's the equality operator for this datatype" problems. > However, the restriction to "true" equality, such that we can assume > x = y implies f(x) = f(y) for every immutable function f on the datatype > (note this need not necessarily mean bitwise equality --- it depends on > what operations the datatype provides), seems like a problem. For > instance, the ordinary = operators on float and numeric are NOT true > equality, nor do we provide any true equality in this sense for these > common datatypes. We could hardly get away with using this concept > to drive foreign-key comparisons, if it doesn't work for float or > numeric. Normally, I would not suggest that we do things only for certain data types only. In this case however, it seems that the reason it would work only for INTEGER and TEXT data types is that they are simple atomic datatypes that have the required properties. So doing this for those datatypes only seems permissable on a theoretical basis, rather than just because we can't be bothered to do it for more complex types. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Online index builds
On Wed, 2006-07-12 at 12:09 -0400, Greg Stark wrote: > no regression tests yet. We'll need some performance tests that show that lock-hold time is *actually* reduced, given the shenanigans needed to get there. We may need to have usage recommendations in the docs. -- Simon Riggs EnterpriseDB http://www.enterprisedb.com ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] pg_dump and inherits issue
"Jim Buttafuoco" <[EMAIL PROTECTED]> writes: > The check constraints on table s are not like the original, I have an extra > t_a_check constraint. Is this correct? I wouldn't say it's correct but it is known. I think the plan is to have such constraints be marked so you *can't* drop them as long as you're a child of another table that has them. But Postgres doesn't yet track where constraints came from or check that you don't drop ones that are inherited. -- greg ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] lastval exposes information that currval does not
On Wed, Jul 12, 2006 at 11:37:37AM -0400, Bruce Momjian wrote: > > Updated text: > >For schemas, allows access to objects contained in the specified >schema (assuming that the objects' own privilege requirements are >also met). Essentially this allows the grantee to look up >objects within the schema. Without this permission, it is still >possible to see the object names by querying the system tables, but >they cannot be accessed via SQL. No, this still misses the point entirely. See all my examples in this thread for ways I have accessed objects without usage to their schema with SQL. ---(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] Three weeks left until feature freeze
Joshua D. Drake wrote: Well I know it isn't an API per say, but one interesting tid bit as an example is that PLphp does not need the PostgreSQL source to compile. It only needs pgxs and the relevant headers etc... Perhaps that is one way to go... All PLs use pgxs? PL/Java does. No source needed. So yes, there's already a fairly good API that assists in the module build process. It does however still include all header files needed by the backend and thus, leaves the backend wide open (in a matter of speech). If a refactoring effort was to start later on, that would be a good place to start. I.e. divide headers into the ones available for external modules and the ones for internal backend use only. Regards, Thomas Hallgren ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] pgsql-patches considered harmful
> > I have the additional complaint that this doesn't actually > solve most > > of my original complaints and might reduce the pressure to > find a better solution. > > The patches announcements themselves would still be basically > > invisible within the community. > > I'm with Greg on this one. I felt his original complaint > made alot of sense and this doesn't really deal with it. I'd > much rather see -patches go away or maybe become an alias to > -hackers. If the patch is too big then perhaps either > compress it or provide a link to it when it's submitted. If > hosting for patches is an issue then perhaps provide a way > for patches to be hosted on a PG server. Honestly, I'd be > happy to put up any PG patches sent to me on a well connected > server. I'm not sure how easy it'd be to automate that > though (and prevent spammers/etc), but perhaps people have > some suggestions? There are list servers out there capable of simply ripping any attachments to a message (possibly over a certain size) and stick it on a website, replacing it with a link in the email. Is majordomo one of them? If that was done, we could just have patches be sent to -hackers, and get rid of -patches completely. //Magnus ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
> I concur with this. The needs for a module like PL/Java is very different > then the needs of PL/Perl so let's get some more PL's in before we do a > refactoring effort to create common API's. Personally, I'm not sure what > would be included. The call handler API's together with the SPI API's are > in essence what you need. The rest is fairly specialized anyway. Well I know it isn't an API per say, but one interesting tid bit as an example is that PLphp does not need the PostgreSQL source to compile. It only needs pgxs and the relevant headers etc... Perhaps that is one way to go... All PLs use pgxs? > As the project grows for various reasons, the number of hackers in the > community will grow as well. PL/Java for instance, does not come without > resources :-) We have already grown for hackers quite a bit this year as they mature I think we will see even more patch review eyes and such... Soon. Sincerely, Joshua D. Drake > > Regards, > Thomas Hallgren > > > ---(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 -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Updateable views for 8.2 or 8.3?
Jaime Casanova wrote: is anybody working on the Bernd Helmle's updateable views patch? or know what the status of this is? I was just wondering about this also. If no one else is working on it, I'd like to try to push it through to completion for 8.2 myself. Can anyone summarize what the open issues are? Joe ---(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] Three weeks left until feature freeze
On Wed, Jul 12, 2006 at 10:14:53AM -0400, Andrew Dunstan wrote: > Hannu Krosing wrote: > >Ühel kenal päeval, K, 2006-07-12 kell 09:49, kirjutas Kaare Rasmussen: > > > >>>There should be a Procedural Language section on pgfoundry for all of the > >>>PLs, IMHO, and a README in contrib within core that points to it > >>>(README.procedural_languages, if nothing else) ... > >>> > >>I thought that the general consensus was that only plpgsql ought to be in > >>core, the rest should be independent projects. > >> > > > >That would be doable if we had a stable language API. > > > >As i understand it, we still dont. And even more - most of the changes > >to API come frome the needs of those (new) languages > > > > > > There is in effect no API at all, other than what is available to all > backend modules. If someone wants to create an API which will be both > sufficiently stable and sufficiently complete to meet the needs of the > various PLs (especially, as Hannu rightly observes, any new PLs that > come along) then we can revisit this question. Until then I suggest > that it is at best premature. I am not even sure such a thing is > actually possible. > > Also there is this: speaking as someone who actually does some work in > this area, I very much appreciate having the eagle eyes of people like > Tom, Neil and Joe on what's going on, and keeping things on the straight > and narrow. I at least would feel lots less comfortable about > maintaining things without such help. If I've caught the right threads... Informix IUS and Illustra had a language manager module which facilitated function resolution and argument marshalling ala SQL and then made the calls to each language in the same API/function call format. Usually I do not like added layers, however, this layer could and should be used to deal with function resolution, type coercion, domains, etc, which is the SQL side. The language itself would have predefined ways of getting arguments and returning data. I'm not sure if this approach would work with the bonus extras on plpgsql, but it should. If anyone wants to pursue this area, please include me on the discussion and I can try to provide information regarding the other implementation. --elein > > The Postgres hacker community is small. I am not sure there is an > adequate pool of people who will maintain the momentum of each > sub-project that we might choose to orphan. If we had thousands of eager > code cutters it might be different, but we don't, really. > > cheers > > andrew > > > > ---(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 > ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
On 7/12/06, Thomas Hallgren <[EMAIL PROTECTED]> wrote: it didn't seem anywhere close production readiness. Perhaps it's no surprise that I disagree when you say PL/J could be considered in the same light as PL/Java. Having used both systems, I have to agree with Thomas; PL/Java is far ahead of PL/J in terms of production readiness. Rather than argue the differences between the architectures... I think it should be looked at on a pro/con basis. Many people have asked for procedural Java and generally pass over PostgreSQL because they don't know about PL/Java or PL/J. In my opinion, having a Java PL included in the core would be ideal. PL/Java seems to be the only Java PL under consistent development and maintenance, so I don't see it as something that would fall on the shoulders of all other maintainers. Just my 2 cents :) -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] Online index builds
I just sent in the patch for online index builds to -patches. . The work to combine the two phases into a single non-transactional command is done. I'm not sure how long to wait between lock checks or how verbose to be about why it's taking so long. I do think we have to print something or else the DBA won't know if it's hung waiting for something external. Currently it prints a notice the first time it sleeps. . Also it prints out how many tuples it found which normal index doesn't. Probably that message should go away. On the other hand the index stats probably need to be filled in. . I need to check what locks I'm taking. I think I still have some old code with the wrong locks in it. . this includes the tid btree opclass sent earlier (with a warning I didn't notice before fixed up). opr_sanity now fails but I think that's due to the gin commits not this opclass. . In case of an error during phase2 the invalid index is left in place. It can be dropped with DROP INDEX. The footwork to get it dropped in case of an error would be quite tricky but there's a sketch of how to do it in the source. . no documentation yet, there's not much to write though. . no regression tests yet. I don't see any way to test this reasonably in the regression tests. I've done some testing myself by building indexes while pgbench is running. Then I have to do index scans to see how many records are returned with index scans. It wouldn't be easy to automate and even if it were done it wouldn't really be all that great a test. The corner cases found during the development are pretty narrow and will be hard to reliably test. -- greg ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
Andrew Dunstan wrote: There is in effect no API at all, other than what is available to all backend modules. If someone wants to create an API which will be both sufficiently stable and sufficiently complete to meet the needs of the various PLs (especially, as Hannu rightly observes, any new PLs that come along) then we can revisit this question. Until then I suggest that it is at best premature. I am not even sure such a thing is actually possible. I concur with this. The needs for a module like PL/Java is very different then the needs of PL/Perl so let's get some more PL's in before we do a refactoring effort to create common API's. Personally, I'm not sure what would be included. The call handler API's together with the SPI API's are in essence what you need. The rest is fairly specialized anyway. Also there is this: speaking as someone who actually does some work in this area, I very much appreciate having the eagle eyes of people like Tom, Neil and Joe on what's going on, and keeping things on the straight and narrow. I at least would feel lots less comfortable about maintaining things without such help. This is partly why I'd like to get PL/Java included. Not that I expect any of them to devote resources to PL/Java but I think that they, from time to time, will visit the code. If not for anything else then to see why some other change caused build failures. It's always easier to have discussions around code that you know they all have on disk. The Postgres hacker community is small. I am not sure there is an adequate pool of people who will maintain the momentum of each sub-project that we might choose to orphan. If we had thousands of eager code cutters it might be different, but we don't, really. As the project grows for various reasons, the number of hackers in the community will grow as well. PL/Java for instance, does not come without resources :-) Regards, Thomas Hallgren ---(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] lastval exposes information that currval does not
Updated text: For schemas, allows access to objects contained in the specified schema (assuming that the objects' own privilege requirements are also met). Essentially this allows the grantee to look up objects within the schema. Without this permission, it is still possible to see the object names by querying the system tables, but they cannot be accessed via SQL. --- Jan Wieck wrote: > On 7/9/2006 8:32 AM, Martijn van Oosterhout wrote: > > > On Sat, Jul 08, 2006 at 05:47:33PM -0400, Jim Nasby wrote: > >> On Jul 6, 2006, at 11:02 AM, Phil Frost wrote: > >> >I hope the above example is strong enough to elicit a comment from a > >> >qualified developer. If it is not, consider that stored procedures > >> >contain prepared statements, and many client applications cache > >> >prepared > >> >statements as well. Thus, revoking usage on a schema is about as > >> >good as > >> >nothing until all sessions have ended. It also means that any function > >> >which operates with OIDs can potentially bypass the schema usage > >> >check. > >> > >> The docs probably should elaborate that once something's been looked > >> up you no longer need permissions on the schema it resides in. > > > > I'm not sure this is really unexpected behaviour. On UNIX it is clearly > > defined that file permissions are checked only on open. Once you've > > opened it, changing permissions on the file won't affect you. If > > someone passes you a read/write descriptor to a file, you can > > read/write it even if you didn't have permissions to open the > > file/socket/whatever yourself. > > This isn't the case and I do agree with Phil on this. The fact that > another "security definer" function did access an object during the > session should not give the user the ability to access it in the manner > shown in his example. lastval() without arguments should not remember > the sequence by its oid only, but also remember the sequences schema and > to a proper ACL check on that as well. > > Just think of it if SELECT without a FROM clause would automatically > assume the same rangetable as the last SELECT in the session. If that > were the case, would you guy's defend the position that "SELECT *" then > should spit out the full content of the last table accessed by the > security definer function just called, even if the user doesn't have > schema permission? I doubt! > > > Jan > > > > > I'm not sure it makes sense to be able to revoke someone's permissions > > on an object they've already accessed. From a transactional point of > > view, the revoke should at the very least not affect transactions > > started prior to the revokation. Some things are shared across an > > entire session, and the rule extends to them. Is this a bug? Maybe, but > > it is debatable. > > > > Have a nice day, > > > -- > #==# > # It's easier to get forgiveness for being wrong than for being right. # > # Let's break this rule - forgive me. # > #== [EMAIL PROTECTED] # > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend -- Bruce Momjian [EMAIL PROTECTED] EnterpriseDBhttp://www.enterprisedb.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] Three weeks left until feature freeze
On 7/12/06, David Fetter <[EMAIL PROTECTED]> wrote: Are they mutually exclusive? I can imagine, at least for development purposes, that someone might want to install both. I believe both can be installed and running at the same time. I don't really think anyone would want to run both, but that's just my opinion. -- Jonah H. Harris, Software Architect | phone: 732.331.1300 EnterpriseDB Corporation| fax: 732.331.1301 33 Wood Ave S, 2nd Floor| [EMAIL PROTECTED] Iselin, New Jersey 08830| http://www.enterprisedb.com/ ---(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] Three weeks left until feature freeze
On Wednesday 12 July 2006 04:15, Dave Cramer wrote: > Absolutely PL/J should be considered in the same light as PL/Java. > > Consider this a request for PL/J to be included in the core. Frankly I don't care which one is used, as long as the one (and ONLY one) that is included is the most mature and stable. Sincerely, Joshua D. Drake > > Dave > > On 11-Jul-06, at 12:50 PM, Josh Berkus wrote: > > David, > > > >> It's good to integrate things with the core as needed. What plans do > >> we have to integrate PL/J? > > > > None, if the PL/J team doesn't speak up. So far I have yet to see > > a request for PL/J or even a release notice. > > > > --Josh > > > > ---(end of > > broadcast)--- > > TIP 5: don't forget to increase your free space map settings > > ---(end of broadcast)--- > TIP 6: explain analyze is your friend -- === The PostgreSQL Company: Command Prompt, Inc. === Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 Providing the most comprehensive PostgreSQL solutions since 1997 http://www.commandprompt.com/ ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
On Wed, Jul 12, 2006 at 07:29:52AM -0700, Joshua D. Drake wrote: > On Wednesday 12 July 2006 04:15, Dave Cramer wrote: > > Absolutely PL/J should be considered in the same light as PL/Java. > > > > Consider this a request for PL/J to be included in the core. > > Frankly I don't care which one is used, as long as the one (and ONLY one) > that > is included is the most mature and stable. Are they mutually exclusive? I can imagine, at least for development purposes, that someone might want to install both. Cheers, D > > Sincerely, > > Joshua D. Drake > > > > > Dave > > > > On 11-Jul-06, at 12:50 PM, Josh Berkus wrote: > > > David, > > > > > >> It's good to integrate things with the core as needed. What plans do > > >> we have to integrate PL/J? > > > > > > None, if the PL/J team doesn't speak up. So far I have yet to see > > > a request for PL/J or even a release notice. > > > > > > --Josh > > > > > > ---(end of > > > broadcast)--- > > > TIP 5: don't forget to increase your free space map settings > > > > ---(end of broadcast)--- > > TIP 6: explain analyze is your friend > > -- >=== The PostgreSQL Company: Command Prompt, Inc. === > Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240 >Providing the most comprehensive PostgreSQL solutions since 1997 > http://www.commandprompt.com/ > -- David Fetter <[EMAIL PROTECTED]> http://fetter.org/ phone: +1 415 235 3778AIM: dfetter666 Skype: davidfetter Remember to vote! ---(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] Three weeks left until feature freeze
Hannu Krosing wrote: Ühel kenal päeval, K, 2006-07-12 kell 09:49, kirjutas Kaare Rasmussen: There should be a Procedural Language section on pgfoundry for all of the PLs, IMHO, and a README in contrib within core that points to it (README.procedural_languages, if nothing else) ... I thought that the general consensus was that only plpgsql ought to be in core, the rest should be independent projects. That would be doable if we had a stable language API. As i understand it, we still dont. And even more - most of the changes to API come frome the needs of those (new) languages There is in effect no API at all, other than what is available to all backend modules. If someone wants to create an API which will be both sufficiently stable and sufficiently complete to meet the needs of the various PLs (especially, as Hannu rightly observes, any new PLs that come along) then we can revisit this question. Until then I suggest that it is at best premature. I am not even sure such a thing is actually possible. Also there is this: speaking as someone who actually does some work in this area, I very much appreciate having the eagle eyes of people like Tom, Neil and Joe on what's going on, and keeping things on the straight and narrow. I at least would feel lots less comfortable about maintaining things without such help. The Postgres hacker community is small. I am not sure there is an adequate pool of people who will maintain the momentum of each sub-project that we might choose to orphan. If we had thousands of eager code cutters it might be different, but we don't, really. cheers andrew ---(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: [PATCHES] [HACKERS] kerberos related warning
Peter Eisentraut wrote: Am Mittwoch, 12. Juli 2006 04:38 schrieb Joe Conway: gcc -O -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic -DFRONTEND -I. -I../../../src/include -D_GNU_SOURCE -I/usr/include/et -I../../../src/port -c -o fe-auth.o fe-auth.c -MMD fe-auth.c: In function 'pg_fe_getauthname': fe-auth.c:573: warning: passing argument 1 of 'free' discards qualifiers from pointer target type I don't see that. Which Kerberos version do you have? I don't think it's related to Kerberos except that the entire problem is #ifdef'd out unless "configure --with-krb5" is used. Maybe more related to gcc version? In any case, I'm running stock fedora core 5: krb5-libs-1.4.3-4.1 gcc-4.1.1-1.fc5 Joe ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Three weeks left until feature freeze
Ühel kenal päeval, K, 2006-07-12 kell 09:49, kirjutas Kaare Rasmussen: > > There should be a Procedural Language section on pgfoundry for all of the > > PLs, IMHO, and a README in contrib within core that points to it > > (README.procedural_languages, if nothing else) ... > > I thought that the general consensus was that only plpgsql ought to be in > core, the rest should be independent projects. That would be doable if we had a stable language API. As i understand it, we still dont. And even more - most of the changes to API come frome the needs of those (new) languages > It would be nice to have an easy way to retrieve and install the desired PL's > but that's more of a packaging issue. > -- Hannu Krosing Database Architect Skype Technologies OÜ Akadeemia tee 21 F, Tallinn, 12618, Estonia Skype me: callto:hkrosing Get Skype for free: http://www.skype.com ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Implied Functional Index use
Am Dienstag, 11. Juli 2006 23:31 schrieb Tom Lane: > We could invent some more-complex concept involving "well, this is > equality, but there are some functions for which f(x) might differ > from f(y) anyway" and then mark the presumably-few functions that > could produce divergent results --- examples are sgn() for float8 > and anything dependent on dscale for numeric. This seems ugly and > error prone however. >From a mathematical point of view, it seems cleaner to attach this property to functions, not operators, namely, "this function preserves the following relations". This would allow extending Simon's idea to other operators such as > and < and possibly more mind-boggling cases with geometric operators and such. Admittedly, this would put a lot of additional typing load on function authors, but perhaps it's safer that way. -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Updateable views for 8.2 or 8.3?
Hi, is anybody working on the Bernd Helmle's updateable views patch? or know what the status of this is? -- regards, Jaime Casanova "Programming today is a race between software engineers striving to build bigger and better idiot-proof programs and the universe trying to produce bigger and better idiots. So far, the universe is winning." Richard Cook ---(end of broadcast)--- TIP 6: explain analyze is your friend
[HACKERS] pg_dump and inherits issue
I have an issue with pg_dump and inherits with pg 8.1.3 and 8.1.4 if I run the following SQL create table t (a text check (a = '*')); create table s () inherits (t); alter table s drop constraint t_a_check; alter table s add constraint a_check check (a='s'); I get the following Table "public.t" Column | Type | Modifiers +--+--- a | text | Check constraints: "t_a_check" CHECK (a = '*'::text) Table "public.s" Column | Type | Modifiers +--+--- a | text | Check constraints: "a_check" CHECK (a = 's'::text) Inherits: t and then create a new database and run pg_dump old_db |psql new_db I get the following Table "public.t" Column | Type | Modifiers +--+--- a | text | Check constraints: "t_a_check" CHECK (a = '*'::text) Table "public.s" Column | Type | Modifiers +--+--- a | text | Check constraints: "a_check" CHECK (a = 's'::text) "t_a_check" CHECK (a = '*'::text) Inherits: t The check constraints on table s are not like the original, I have an extra t_a_check constraint. Is this correct? Jim ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] kerberos related warning
Am Mittwoch, 12. Juli 2006 04:38 schrieb Joe Conway: > > gcc -O -Wall -Wmissing-prototypes -Wpointer-arith -Winline > > -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -g > > -pthread -D_REENTRANT -D_THREAD_SAFE -D_POSIX_PTHREAD_SEMANTICS -fpic > > -DFRONTEND -I. -I../../../src/include -D_GNU_SOURCE -I/usr/include/et > > -I../../../src/port -c -o fe-auth.o fe-auth.c -MMD > > fe-auth.c: In function 'pg_fe_getauthname': > > fe-auth.c:573: warning: passing argument 1 of 'free' discards qualifiers > > from pointer target type I don't see that. Which Kerberos version do you have? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
Am Dienstag, 11. Juli 2006 17:40 schrieb Alvaro Herrera: > We've discussed this before, regarding PL/php IIRC. The conclusions the > last time around, as far as I remember, was that we wanted the PLs to be > in the same CVS repo, but able to be compiled separately from the whole > source tree. That was precisely what I recall. But if we make them separate CVS modules, they would not have the same branch structure, or would they? -- Peter Eisentraut http://developer.postgresql.org/~petere/ ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Three weeks left until feature freeze
Hi Dave, Sorry I missed you at the Summit. I would've liked to discuss PL/J versus PL/Java with you. What is the status of PL/J? I haven't seen much activity there over the last 10 months. Does it run on Windows yet? Are you planning a first release anytime soon? Do you have any active users? Does the project still have over 40 dependencies to other components? The last time I looked (August last year) a beta-0.1.1 was planned. I didn't manage to built it and it didn't seem anywhere close production readiness. Perhaps it's no surprise that I disagree when you say PL/J could be considered in the same light as PL/Java. Then again, I'm fairly biased ;-) Regards, Thomas Hallgren Dave Cramer wrote: Absolutely PL/J should be considered in the same light as PL/Java. Consider this a request for PL/J to be included in the core. Dave On 11-Jul-06, at 12:50 PM, Josh Berkus wrote: David, It's good to integrate things with the core as needed. What plans do we have to integrate PL/J? None, if the PL/J team doesn't speak up. So far I have yet to see a request for PL/J or even a release notice. --Josh ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Three weeks left until feature freeze
Kaare Rasmussen wrote: There should be a Procedural Language section on pgfoundry for all of the PLs, IMHO, and a README in contrib within core that points to it (README.procedural_languages, if nothing else) ... I thought that the general consensus was that only plpgsql ought to be in core, the rest should be independent projects. Quite the contrary, if anything. cheers andrew ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Three weeks left until feature freeze
Marc G. Fournier wrote: There should be a Procedural Language section on pgfoundry for all of the PLs, IMHO, and a README in contrib within core that points to it (README.procedural_languages, if nothing else) ... This was a bad idea last time it was proposed and is still a bad idea for the same reasons that caused it to be rejected then. cheers andrew ---(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] Three weeks left until feature freeze
Absolutely PL/J should be considered in the same light as PL/Java. Consider this a request for PL/J to be included in the core. Dave On 11-Jul-06, at 12:50 PM, Josh Berkus wrote: David, It's good to integrate things with the core as needed. What plans do we have to integrate PL/J? None, if the PL/J team doesn't speak up. So far I have yet to see a request for PL/J or even a release notice. --Josh ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Three weeks left until feature freeze
> There should be a Procedural Language section on pgfoundry for all of the > PLs, IMHO, and a README in contrib within core that points to it > (README.procedural_languages, if nothing else) ... I thought that the general consensus was that only plpgsql ought to be in core, the rest should be independent projects. It would be nice to have an easy way to retrieve and install the desired PL's but that's more of a packaging issue. -- Med venlig hilsen Kaare Rasmussen, Jasonic Jasonic Telefon: +45 3816 2582 Nordre Fasanvej 12 2000 Frederiksberg Email: [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
[HACKERS] Resurrecting per-page cleaner for btree
Hi Hackers, Can we resurrect the patch proposed by Junji TERAMOTO? It removes unnecessary items before btree pages split. http://archives.postgresql.org/pgsql-patches/2006-01/msg00301.php There was a problem in the patch when we restarted scans from deleted tuples. But now we scan pages at-a-time, so the problem is resolved, isn't it? http://archives.postgresql.org/pgsql-patches/2006-05/msg8.php I think this feature is independent from the SITC project and useful for heavily-updated indexes. If it is worthwhile, I'll revise the patch to catch up on HEAD. Regards, --- ITAGAKI Takahiro NTT Open Source Software Center ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq