Re: [HACKERS] Merge algorithms for large numbers of tapes
This amounts to an assumption that you have infinite work_mem, in which case you hardly need an external sort at all. If your work_mem is in fact finite, then at some point you need more than two passes. I'm not really interested in ripping out support for sort operations that are much larger than work_mem. No it does not. I have explained this before. You can have one million files and merge them all into a final output with a single pass. It does not matter how big they are or how much memory you have. Hh ? But if you have too many files your disk access is basically then going to be random access (since you have 1000nds of files per spindle). From tests on AIX I have pretty much concluded, that if you read 256k blocks at a time though, random access does not really hurt that much any more. So, if you can hold 256k per file in memory that should be sufficient. Andreas ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Merge algorithms for large numbers of tapes
Ühel kenal päeval, K, 2006-03-08 kell 20:08, kirjutas Jim C. Nasby: But it will take a whole lot of those rewinds to equal the amount of time required by an additional pass through the data. I guess that missing a sector read also implies a rewind, i.e. if you don't process the data read from a tape fast enough, you will have to wait a whole disc revolution (~== seek time on modern disks) before you get the next chunk of data. I'll venture a guess that as long as you've got enough memory to still read chunks back in 8k blocks that it won't be possible for a multi-pass sort to out-perform a one-pass sort. Especially if you also had the ability to do pre-fetching (not something to fuss with now, but certainly a possibility in the future). In any case, what we really need is at least good models backed by good drive performance data. And filesystem performance data, as postgres uses OS-s native filesystems. -- Hannu ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL
On Wed, Mar 08, 2006 at 06:42:45PM -0500, Greg Stark wrote: Ben Chelf [EMAIL PROTECTED] writes: #ifdef STATIC_ANALYSIS #define ereport(elevel, rest) \ (errstart(elevel, __FILE__, __LINE__, PG_FUNCNAME_MACRO) ? \ (errfinish rest) : (void) 0), (elevel = ERROR ? exit(0) : 0) #else /* Normal def */ #endif As for Coverity, if the elevel that's passed to the ereport is really a constant, the above #ifdef should absolutely do the trick for us so we know to stop analyzing on that path...Let me know if it doesn't actually do that ;) If you're willing to require elevel to always be a constant then why not just tack on the (elevel = ERROR ? exit(0) : 0) onto the end of the regular definition of ereport instead of having an ifdef? Well, the only cost would be a useless call to exit() for each elog/ereport with an elevel = ERROR. It bloats the binary a bit. Not sure whether people care enough about that. 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] [COMMITTERS] pgsql: Remove Christof Petig copyright on include file,
On Wed, Mar 08, 2006 at 05:31:47PM -0500, Bruce Momjian wrote: We should not have individual copyrights to individuals in our source tree. If Jan's is in there, it should be removed too (with his approval). The only copyright holder should be PostgreSQL Global Development Group. Err, to do that someone would need to collect copyright assignments (ie signed documents) from every single contributer, including people no longer associated with the project. That is something you can do if you start doing it when the project starts but it way too late for that now. 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] Coverity Open Source Defect Scan of PostgreSQL
Martijn van Oosterhout wrote: -- Start of PGP signed section. On Wed, Mar 08, 2006 at 06:42:45PM -0500, Greg Stark wrote: Ben Chelf [EMAIL PROTECTED] writes: #ifdef STATIC_ANALYSIS #define ereport(elevel, rest) \ (errstart(elevel, __FILE__, __LINE__, PG_FUNCNAME_MACRO) ? \ (errfinish rest) : (void) 0), (elevel = ERROR ? exit(0) : 0) #else /* Normal def */ #endif As for Coverity, if the elevel that's passed to the ereport is really a constant, the above #ifdef should absolutely do the trick for us so we know to stop analyzing on that path...Let me know if it doesn't actually do that ;) If you're willing to require elevel to always be a constant then why not just tack on the (elevel = ERROR ? exit(0) : 0) onto the end of the regular definition of ereport instead of having an ifdef? Well, the only cost would be a useless call to exit() for each elog/ereport with an elevel = ERROR. It bloats the binary a bit. Not sure whether people care enough about that. We care. :-) -- 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] [COMMITTERS] pgsql: Remove Christof Petig copyright on include file,
Martijn van Oosterhout kleptog@svana.org writes: On Wed, Mar 08, 2006 at 05:31:47PM -0500, Bruce Momjian wrote: The only copyright holder should be PostgreSQL Global Development Group. Err, to do that someone would need to collect copyright assignments (ie signed documents) from every single contributer, including people no longer associated with the project. That is something you can do if you start doing it when the project starts but it way too late for that now. Not for copyrights in the name of people who are still around, which is 99% of the issue. regards, tom lane ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Merge algorithms for large numbers of tapes
* Greg Stark: That's one thing that gives me pause about the current approach of using more tapes. It seems like ideally the user would create a temporary work space on each spindle and the database would arrange to use no more than that number of tapes. Then each merge operation would involve only sequential access for both reads and writes. And you'd need to preallocate the files in some way or other, to avoid file system fragmentation. ---(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
[HACKERS] Proposal for SYNONYMS
This email is a preliminary design for the implementation of synonyms in PostgreSQL. Comments and suggestions are welcomed. BACKGROUND Synonyms are database objects which can be used in place of their referenced object in SELECT, INSERT, UPDATE, and DELETE SQL statements. There are two reasons to use synonyms which include: - Abstraction from changes made to the name or location of database objects - Alternative naming for another database object Similarly, RDBMS support for synonyms exists in Oracle, SQL Server, DB2, SAP DB/MAX DB, and Mimer. PROPOSED SQL ADDITIONS CREATE SYNONYM qualified_name FOR qualified_name DROP SYNONYM qualified_name In addition, SYNONYMS do participate in ACLs and support GRANT/REVOKE for table privileges. DROP TABLE and TRUNCATE cannot be used with synonyms. DESCRIPTION - A synonym can be created for a table, view, or synonym. - Synonyms can reference objects in any schema RESTRICTIONS - A synonym may only be created if the creator has some access privilege on the referenced object. - A synonym can only be created for an existing table, view or synonym. - A synonym name cannot be the same as the name of any other table, view or synonym which exists in the schema where the synonym is to be created. PROPOSED IMPLEMENTATION - Introduce a new relkind for synonyms - Synonyms only act as pointers to a real object by oid - Permission on a synonym does not override the permission on the referenced object - Referenced objects becomes dependencies of the synonyms that reference them - Synonyms follow PostgreSQL's current search_path behavior RUNTIME COST - Dependent on database user/administrator - In catalog searches which do not reference a synonym, the only cost incurred is that of searching the additional number of synonym objects in the catalog - In catalog searches which use a synonym, an additional cost is incurred to reference the real object - If no synonyms are created, no additional costs are incurred -- Jonah H. Harris, Database Internals ArchitectEnterpriseDB Corporation732.331.1324
Re: [HACKERS] Merge algorithms for large numbers of tapes
Jim, On 3/9/06 8:35 AM, Jim C. Nasby [EMAIL PROTECTED] wrote: Well, the reality remains though; most folks are unlikely to setup enough dedicated temp areas so that we can do one tape per disk, so it would be really good to have a sort method that didn't rely on that. Agreed - however optimizing the run output and merge pass is straightforward without knowing the underlying I/O infrastructure. Consider that a popular commercial database, running on a 6-disk RAID5 with one filesystem, performs external sorting 4 times faster (1/4 of the time) than Postgres using a two pass sort. There is no special optimization of the I/O path involved, it's simply a matter of using a modern external sorting approach (no tapes). Tom's point about finite memory is definitely important - it does take roughly SQRT(sort set) of memory to perform the two pass sort, but that is a completely manageable amount of memory. The problem we have now is that we don't use a dynamic memory allocation mechanism to provide this amount of RAM to the task. That's why the tape algorithm is safe, because you can guarantee an external sort result, even with tiny memory. But I believe the right answer is to implement the modern sorting algorithm and the memory allocation to support it. Sorting is too important to most operations to be so far behind - 400% slower is not acceptable, and I don't think tweaking the current approach will get us there. - Luke ---(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] Proposal for SYNONYMS
On 3/9/06, William ZHANG [EMAIL PROTECTED] wrote: Or should we letDROP TABLE foo CASCADE;to drop the SYNONYMS depended on the table? Yes, I don't see any reason not to allow a cascading table drop include synonyms that reference them. Also need to add \d support for psql. Yes. Thanks for adding that. -- Jonah H. Harris, Database Internals ArchitectEnterpriseDB Corporation732.331.1324
Re: [HACKERS] Proposal for SYNONYMS
* Jonah H. Harris ([EMAIL PROTECTED]) wrote: In addition, SYNONYMS do participate in ACLs and support GRANT/REVOKE for table privileges. DROP TABLE and TRUNCATE cannot be used with synonyms. I assume you actually mean owner-level rights cannot be used with synonyms. - Permission on a synonym does not override the permission on the referenced object Need to be careful here and also make sure schema-level permissions aren't able to be circumvented. Sounds good to me in general though. Thanks! Stephen signature.asc Description: Digital signature
Re: [HACKERS] Proposal for SYNONYMS
* Jonah H. Harris ([EMAIL PROTECTED]) wrote: On 3/9/06, William ZHANG [EMAIL PROTECTED] wrote: Or should we let DROP TABLE foo CASCADE; to drop the SYNONYMS depended on the table? Yes, I don't see any reason not to allow a cascading table drop include synonyms that reference them. Should a non-cascade drop fail or just implicitly drop the synonyms? I'm not sure which way I feel about this... Users with only 'select' permissions on a given object can't currently create objects which depend on that object (such that dropping the object would then require 'cascade'), can they? I'd tend to think the synonyms should just be implicitly dropped. The creator of the table doesn't necessairly have any knowledge (or care) about synonyms which anyone with access to the table could have created... Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] problem with large maintenance_work_mem settings and
Stefan Kaltenbrunner [EMAIL PROTECTED] writes: samples %symbol name 103520432 47.9018 inlineApplySortFunction 33382738 15.4471 comparetup_index 25296438 11.7054 tuplesort_heap_siftup 10089122 4.6685 btint4cmp 8395676 3.8849 LogicalTapeRead 2873556 1.3297 tuplesort_heap_insert 2796545 1.2940 tuplesort_gettuple_common 2752345 1.2736 AllocSetFree 2233889 1.0337 IndexBuildHeapScan Interesting. What's the platform, and what compiler exactly? For me, gcc seems to inline inlineApplySortFunction successfully, but your compiler evidently is not doing that. I get a significantly different oprofile result from CVS HEAD: CPU: P4 / Xeon with 2 hyper-threads, speed 2793.08 MHz (estimated) Counted GLOBAL_POWER_EVENTS events (time during which processor is not stopped) with a unit mask of 0x01 (mandatory) count 24 samples %symbol name 194439 37.8399 tuplesort_heap_siftup 7080313.7790 comparetup_index 35030 6.8172 btint4cmp 25139 4.8923 AllocSetAlloc 23965 4.6638 writetup_index 18057 3.5141 GetMemoryChunkSpace 17384 3.3831 tuplesort_gettuple_common 14356 2.7938 mergepreread 12740 2.4793 LWLockAcquire 11175 2.1748 LWLockRelease 6986 1.3596 tuplesort_heap_insert 6659 1.2959 PageAddItem 6387 1.2430 index_form_tuple 5225 1.0168 LogicalTapeRead LOG: begin index sort: unique = f, workMem = 65536, randomAccess = f LOG: switching to external sort with 234 tapes: CPU 0.23s/0.81u sec elapsed 1.82 sec LOG: finished writing run 1 to tape 0: CPU 0.68s/6.80u sec elapsed 9.59 sec LOG: finished writing run 2 to tape 1: CPU 1.23s/13.54u sec elapsed 17.88 sec LOG: finished writing run 3 to tape 2: CPU 1.62s/20.43u sec elapsed 25.56 sec LOG: finished writing run 4 to tape 3: CPU 2.08s/27.48u sec elapsed 34.64 sec LOG: finished writing run 5 to tape 4: CPU 2.56s/34.50u sec elapsed 43.06 sec LOG: performsort starting: CPU 2.66s/35.81u sec elapsed 45.00 sec LOG: finished writing run 6 to tape 5: CPU 2.74s/38.11u sec elapsed 47.38 sec LOG: finished writing final run 7 to tape 6: CPU 2.74s/38.15u sec elapsed 47.43 sec LOG: performsort done (except 7-way final merge): CPU 2.74s/38.56u sec elapsed 47.84 sec LOG: external sort ended, 24434 disk blocks used: CPU 4.10s/51.98u sec elapsed 65.33 sec This is creating an index on a single integer column, 10 million rows, random data, with maintenance_work_mem set to 65536 (64MB). Platform is 64-bit Xeon, Fedora Core 4. I tried a larger test case (100M rows, 640MB maintenance_work_mem) and got similar results, with if anything a few more percent in tuplesort_heap_siftup. What's even more interesting is that an instruction-level dump of the oprofile counts shows that almost all the tuplesort_heap_siftup time is spent at the ((tup1)-tupindex != (tup2)-tupindex) part of the first HEAPCOMPARE macro. I interpret this as memory fetch delay: that's the first touch of the SortTuple array elements, and if that part of the array wasn't in L2 cache this is where the CPU would stall waiting for it. Your machine seems not to be subject to nearly the same amount of memory delay. Which is interesting because most of the argument for changing sort algorithms seems to hinge on the assumption that main-memory delay is the main thing we need to worry about. That looks to be valid on the Xeon I'm testing but not on your machine ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Proposal for SYNONYMS
Jonah H. Harris wrote: This email is a preliminary design for the implementation of synonyms in PostgreSQL. Comments and suggestions are welcomed. BACKGROUND Synonyms are database objects which can be used in place of their referenced object in SELECT, INSERT, UPDATE, and DELETE SQL statements. There are two reasons to use synonyms which include: - Abstraction from changes made to the name or location of database objects - Alternative naming for another database object Similarly, RDBMS support for synonyms exists in Oracle, SQL Server, DB2, SAP DB/MAX DB, and Mimer. PROPOSED SQL ADDITIONS CREATE SYNONYM qualified_name FOR qualified_name DROP SYNONYM qualified_name In addition, SYNONYMS do participate in ACLs and support GRANT/REVOKE for table privileges. DROP TABLE and TRUNCATE cannot be used with synonyms. DESCRIPTION - A synonym can be created for a table, view, or synonym. - Synonyms can reference objects in any schema RESTRICTIONS - A synonym may only be created if the creator has some access privilege on the referenced object. - A synonym can only be created for an existing table, view or synonym. - A synonym name cannot be the same as the name of any other table, view or synonym which exists in the schema where the synonym is to be created. PROPOSED IMPLEMENTATION - Introduce a new relkind for synonyms - Synonyms only act as pointers to a real object by oid - Permission on a synonym does not override the permission on the referenced object - Referenced objects becomes dependencies of the synonyms that reference them - Synonyms follow PostgreSQL's current search_path behavior RUNTIME COST - Dependent on database user/administrator - In catalog searches which do not reference a synonym, the only cost incurred is that of searching the additional number of synonym objects in the catalog - In catalog searches which use a synonym, an additional cost is incurred to reference the real object - If no synonyms are created, no additional costs are incurred hi jonah ... the main problem i can see here is that it is strictly limited to objects stored in pg_class. however, support for stored procedures would be cool as well. what do you suggest for those? best regards, hans -- Cybertec Geschwinde Schönig GmbH Schöngrabern 134; A-2020 Hollabrunn Tel: +43/1/205 10 35 / 340 www.postgresql.at, www.cybertec.at ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal for SYNONYMS
* Stephan Szabo ([EMAIL PROTECTED]) wrote: On Thu, 9 Mar 2006, Stephen Frost wrote: Should a non-cascade drop fail or just implicitly drop the synonyms? I'm not sure which way I feel about this... Users with only 'select' permissions on a given object can't currently create objects which depend on that object (such that dropping the object would then require 'cascade'), can they? I think a user can create a view to a table they only have select on right now and that should prevent non-cascade drops as well. Hmm, alright, fair enough. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] problem with large maintenance_work_mem settings and
Tom Lane wrote: Stefan Kaltenbrunner [EMAIL PROTECTED] writes: samples %symbol name 103520432 47.9018 inlineApplySortFunction 33382738 15.4471 comparetup_index 25296438 11.7054 tuplesort_heap_siftup 10089122 4.6685 btint4cmp 8395676 3.8849 LogicalTapeRead 2873556 1.3297 tuplesort_heap_insert 2796545 1.2940 tuplesort_gettuple_common 2752345 1.2736 AllocSetFree 2233889 1.0337 IndexBuildHeapScan Interesting. What's the platform, and what compiler exactly? For me, gcc seems to inline inlineApplySortFunction successfully, but your compiler evidently is not doing that. Debian Sarge/AMD64 with gcc version 3.3.5 (Debian 1:3.3.5-13) running on a Dual AMD Opteron 280 (so 4 cores @2,4GHz) with 16GB of RAM and a very recent Kernel. Debian has gcc 3.4 as an optional package in Sarge too so I certainly can try that one. [...] Your machine seems not to be subject to nearly the same amount of memory delay. Which is interesting because most of the argument for changing sort algorithms seems to hinge on the assumption that main-memory delay is the main thing we need to worry about. That looks to be valid on the Xeon I'm testing but not on your machine ... hmm very interesting, Opterons are known for there very high memory bandwidth and some (rather limited) testing using various benchmarktools against a 3,2Ghz DP Xeon with 2MB L2 cache shows that the Opteron box really has a significant advantage here ... Stefan ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] PostgreSQL Anniversary Summit, Call for Contributions
On Tue, Mar 07, 2006 at 08:56:23AM -, Dave Page wrote: Do you have someone with some local knowledge who can recommend some nearby hotels? Yes. If you go to http://conference.postgresql.org/Location/, I've put up some information about this. I'll be expanding those pages as things move along. BTW, now that we seem to be really underway, I'll also likely be contacting known-to-be-local people and hitting them up for specific things we might need. The organisers group was (at my insistence, so you all can blame me) kept small initially because the timeline for this was, I thought, extremely compressed (so I thought we had to nail down some things before we started getting too many people involved). If you are local to the Toronto area, are willing to help with the many on-the-ground things that are likely needed to be done, and will be available to do so, I eagerly solicit your help. Please contact me off list in that case. A -- Andrew Sullivan | [EMAIL PROTECTED] The plural of anecdote is not data. --Roger Brinner ---(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] Coverity Open Source Defect Scan of PostgreSQL
Marc G. Fournier [EMAIL PROTECTED] writes: Why? I don't think we are able to run 'embedded' now as it is, so its not like we're dealign with system with small disk spaces :) how much bigger would adding that exit() make the binary? It's not only the exit(), as the elevel parameter isn't always a constant. The proposed patch would at a minimum expose us to double-evaluation risks. I kinda doubt there are any cases where an elevel parameter expression has side-effects, so that objection may be mostly hypothetical, but nonetheless we are talking about more than just wasting a few bytes. It's not impossible that the patch would introduce outright bugs. Consider something like /* ENOENT is expected, anything else is not */ elog(errno == ENOENT ? DEBUG : ERROR, ...) By the time control comes back from elog, errno would likely be different, and so this would result in an unexpected exit() call if the patch is in place. I'd be the first to call the above poor coding, but it wouldn't be a bug ... unless the errno is rechecked. It's been asserted that Coverity can be taught to understand about elog/ereport without this sort of hack, so I'd rather take that tack. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL
Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: Why? I don't think we are able to run 'embedded' now as it is, so its not like we're dealign with system with small disk spaces :) how much bigger would adding that exit() make the binary? It's not only the exit(), as the elevel parameter isn't always a constant. The proposed patch would at a minimum expose us to double-evaluation risks. I kinda doubt there are any cases where an elevel parameter expression has side-effects, so that objection may be mostly hypothetical, but nonetheless we are talking about more than just wasting a few bytes. It's not impossible that the patch would introduce outright bugs. Consider something like /* ENOENT is expected, anything else is not */ elog(errno == ENOENT ? DEBUG : ERROR, ...) By the time control comes back from elog, errno would likely be different, and so this would result in an unexpected exit() call if the patch is in place. I'd be the first to call the above poor coding, but it wouldn't be a bug ... unless the errno is rechecked. It's been asserted that Coverity can be taught to understand about elog/ereport without this sort of hack, so I'd rather take that tack. Agreed. The idea of modifying our binary in any way to help a sanity tool not complain is totally backwards. -- 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
Re: [HACKERS] PostgreSQL Anniversary Summit, Call for Contributions
On Thu, 9 Mar 2006 15:13:54 -0500 Andrew Sullivan [EMAIL PROTECTED] wrote: BTW, now that we seem to be really underway, I'll also likely be contacting known-to-be-local people and hitting them up for specific things we might need. The organisers group was (at my insistence, so you all can blame me) kept small initially because the timeline for this was, I thought, extremely compressed (so I thought we had to nail down some things before we started getting too many people involved). If you are local to the Toronto area, are willing to help with the many on-the-ground things that are likely needed to be done, and will be available to do so, I eagerly solicit your help. Please contact me off list in that case. What type of things will you be needing? I can probably spare some time. -- D'Arcy J.M. Cain darcy@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] PostgreSQL Anniversary Summit, Call for Contributions
On Thu, 9 Mar 2006 16:18:43 -0500 D'Arcy J.M. Cain darcy@druid.net wrote: What type of things will you be needing? I can probably spare some time. Doh! Sorry about that. I did reply instead of reply all thinking it would only go to Andrew. I didn't meant to send to the list. -- D'Arcy J.M. Cain darcy@druid.net | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 425 1212 (DoD#0082)(eNTP) | what's for dinner. ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Proposal for SYNONYMS
Jonah, This email is a preliminary design for the implementation of synonyms in PostgreSQL. Comments and suggestions are welcomed. 1) Is there a SQL standard for this? 2) For my comprehension, what's the difference between a SYNONYM and a single-object (possibly updatable) view? -- --Josh Josh Berkus Aglio Database Solutions San Francisco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Proposal for SYNONYMS
On 3/9/06, Josh Berkus josh@agliodbs.com wrote: 1) Is there a SQL standard for this? Nope. 2) For my comprehension, what's the difference between a SYNONYM and asingle-object (possibly updatable) view? Not a whole lot actually. If we had updateable views, I'd suggest that people change their create synonym syntax to create view. However, it would take substantially more work to implement updatable views than synonyms and the functionality of updatable views is substantially different than the use of synonyms alone. If/when updatable views are implemented, I wouldn't have a problem switching create synonym to actually create a view.-- Jonah H. Harris, Database Internals ArchitectEnterpriseDB Corporation732.331.1324
Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL
* Bruce Momjian (pgman@candle.pha.pa.us) wrote: It's been asserted that Coverity can be taught to understand about elog/ereport without this sort of hack, so I'd rather take that tack. Agreed. The idea of modifying our binary in any way to help a sanity tool not complain is totally backwards. This is very amusing. I have to agree w/ Tom in general, the code in this case does the right thing and the Coverity tool should be able to be told about that. However, for areas where the tool is actually right and there's some bug in Postgres, well, I'd hope we'd modify Postgres to fix the bug... ;) Enjoy, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL
On Thu, 9 Mar 2006, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: Why? I don't think we are able to run 'embedded' now as it is, so its not like we're dealign with system with small disk spaces :) how much bigger would adding that exit() make the binary? It's not only the exit(), as the elevel parameter isn't always a constant. The proposed patch would at a minimum expose us to double-evaluation risks. I kinda doubt there are any cases where an elevel parameter expression has side-effects, so that objection may be mostly hypothetical, but nonetheless we are talking about more than just wasting a few bytes. It's not impossible that the patch would introduce outright bugs. Consider something like /* ENOENT is expected, anything else is not */ elog(errno == ENOENT ? DEBUG : ERROR, ...) By the time control comes back from elog, errno would likely be different, and so this would result in an unexpected exit() call if the patch is in place. I'd be the first to call the above poor coding, but it wouldn't be a bug ... unless the errno is rechecked. It's been asserted that Coverity can be taught to understand about elog/ereport without this sort of hack, so I'd rather take that tack. I realize that this might sound 'odd' ... but, would it maybe make sense to document the code around stuff like this as to why we do it the way we do? Basically, we're debating how we could change the code to clean things up for Coverity's analysis, and by the fact that we're getting both sides of the discussion, there are ppl that think that the code could/should be changed ... the arguments against make sense, but instead of coming back to revisit this some time in the future, documenting it in the code as to why we are doing it this way in the first place might save time? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] Proposal for SYNONYMS
On Thu, 9 Mar 2006, Josh Berkus wrote: Jonah, This email is a preliminary design for the implementation of synonyms in PostgreSQL. Comments and suggestions are welcomed. 1) Is there a SQL standard for this? 2) For my comprehension, what's the difference between a SYNONYM and a single-object (possibly updatable) view? I think with the plan as described, the permissions handling is slightly different from how we handle views. As I understood the synonym plan, a person with select on the synonym but not on the referenced table wouldn't be able to select through the synonym, while if the view was created by someone with select a person with select on the view could select through the view. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Proposal for SYNONYMS
On 3/9/06, Stephan Szabo [EMAIL PROTECTED] wrote: As I understood the synonym plan, aperson with select on the synonym but not on the referenced table wouldn'tbe able to select through the synonym, while if the view was created bysomeone with select a person with select on the view could select through the view. In this respect, synonyms are surely different from views. Due to this, I was pondering whether synonyms should have ACLs or whether they just pointed to the object and ACLs were handled as they currently are. I didn't think of a use case for them being different, but I know three of the RDBMS vendors did implement them to have their own permissions, so there's gotta be some reason for it. I'm guessing the reason is for accessing remote database tables which isn't part of this proposal, however, it's generally easier to add it now than later. I'm not averse to removing ACLs from synonyms right now at all as we'd still benefit from the same functionality. -- Jonah H. Harris, Database Internals ArchitectEnterpriseDB Corporation732.331.1324
Re: [HACKERS] Proposal for SYNONYMS
Stephan Szabo [EMAIL PROTECTED] writes: On Thu, 9 Mar 2006, Josh Berkus wrote: 2) For my comprehension, what's the difference between a SYNONYM and a single-object (possibly updatable) view? I think with the plan as described, the permissions handling is slightly different from how we handle views. As I understood the synonym plan, a person with select on the synonym but not on the referenced table wouldn't be able to select through the synonym, while if the view was created by someone with select a person with select on the view could select through the view. I was under the impression that privileges on the synonym wouldn't mean anything at all, with the exception that we'd track its ownership to determine who is allowed to drop the synonym. The point about views is a good one. I don't buy the argument that we should do synonyms instead of updatable views because it's easier. We *will* do updatable views at some point because (a) the spec requires it and (b) it's clearly useful. I'm not eager to be stuck with synonyms forever because somebody thought they could implement one and not the other. (BTW, there was some work being done on updatable views, but I think it's stalled. I suspect the reason is that our current rule system is just too odd to support updatable views reasonably. I've been wondering if an implementation based on allowing triggers on views would be any more manageable.) regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Proposal for SYNONYMS
On Thu, Mar 09, 2006 at 04:42:43PM -0500, Jonah H. Harris wrote: On 3/9/06, Josh Berkus josh@agliodbs.com wrote: 1) Is there a SQL standard for this? Nope. 2) For my comprehension, what's the difference between a SYNONYM and a single-object (possibly updatable) view? Not a whole lot actually. If we had updateable views, I'd suggest that people change their create synonym syntax to create view. However, it would take substantially more work to implement updatable views than synonyms and the functionality of updatable views is substantially different than the use of synonyms alone. If/when updatable views are implemented, I wouldn't have a problem switching create synonym to actually create a view. Since updateable views are relatively easy to construct using rules I'm not sure an entire new syntax is necessary. --elein [EMAIL PROTECTED] -- Jonah H. Harris, Database Internals Architect EnterpriseDB Corporation 732.331.1324 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Merge algorithms for large numbers of tapes
Tom, On 3/9/06 9:44 AM, Tom Lane [EMAIL PROTECTED] wrote: I think this argumentation hinges on some irrational aversion to the word tape. Given adequate work_mem, the CVS-tip behavior is exactly what you propose already (at least for the cases where we don't need random access to the sort result). Nope. There's the matter of this thing called logtape.c, in addition to the use of the tape as a means of grouping runs. In the current implementation, runs are not tapes, and tapes as used in the implementation are an abstraction that only obscures the underlying processes in a meaningful way. My objection to tapes is a rational one, and we have internally demonstrated that by eliminating logtape.c and large hunks of tape algorithm related code, we get slightly faster performance with 2,000 fewer lines of code, ergo, the code is not useful. We did this in two days of work, and in the process uncovered the fact that access was always set to RANDOM, the import of which we've seen discussed here. AFAICS the only result of removing the support for multipass merge is that the code would fail, rather than run slowly, if it didn't have adequate work_mem for a particular problem. Somehow I don't see that as an improvement. I would only suggest that we replace the existing algorithm with one that will work regardless of (reasonable) memory requirements. Perhaps we can agree that at least 1MB of RAM for external sorting will always be available and proceed from there? - Luke ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Proposal for SYNONYMS
Ühel kenal päeval, N, 2006-03-09 kell 11:35, kirjutas Jonah H. Harris:
This email is a preliminary design for the implementation of synonyms
in PostgreSQL. Comments and suggestions are welcomed.
BACKGROUND
Synonyms are database objects which can be used in place of their
referenced object in SELECT, INSERT, UPDATE, and DELETE SQL
statements.
There are two reasons to use synonyms which include:
- Abstraction from changes made to the name or location of database
objects
- Alternative naming for another database object
Similarly, RDBMS support for synonyms exists in Oracle, SQL Server,
DB2, SAP DB/MAX DB, and Mimer.
PROPOSED SQL ADDITIONS
CREATE SYNONYM qualified_name FOR qualified_name
I would like to be able to also have synonyms for DATABASEs, that way
all kinds on online migration tasks should be easier.
so the syntax would be
CREATE SYNONYM qualified_name FOR {TABLE|DATABASE} qualified_name;
DROP SYNONYM qualified_name
In addition, SYNONYMS do participate in ACLs and support GRANT/REVOKE
for table privileges.
Why separate ACL's for synonyms. I'd rather like them to be like unix
filenames - any change of permissions on synonym actually changes
permissions for underlying object. synonyms themselves should be
ACL-less.
DROP TABLE and TRUNCATE cannot be used with synonyms.
I understand why no DROP TABLE, but why forbid TRUNCATE ?
DESCRIPTION
- A synonym can be created for a table, view, or synonym.
will as synonym created on antother synonym internally reference that
other synonym, or directly the final object. I'd prefer the latter, as
this will be cheaper when accessing the object throug synonym, and also
(arguably) clearer/cleaner.
- Synonyms can reference objects in any schema
RESTRICTIONS
- A synonym may only be created if the creator has some access
privilege on the referenced object.
- A synonym can only be created for an existing table, view or
synonym.
- A synonym name cannot be the same as the name of any other table,
view or synonym which exists in the schema where the synonym is to be
created.
PROPOSED IMPLEMENTATION
- Introduce a new relkind for synonyms
- Synonyms only act as pointers to a real object by oid
Aha, so they act like links, not like symlinks
- Permission on a synonym does not override the permission on the
referenced object
So there is no need for separate permissions on synonym. Or is there
some use-case for it ?
- Referenced objects becomes dependencies of the synonyms that
reference them
- Synonyms follow PostgreSQL's current search_path behavior
---
Hannu
---(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] Merge algorithms for large numbers of tapes
Luke Lonergan [EMAIL PROTECTED] writes: I would only suggest that we replace the existing algorithm with one that will work regardless of (reasonable) memory requirements. Perhaps we can agree that at least 1MB of RAM for external sorting will always be available and proceed from there? If you can sort indefinitely large amounts of data with 1MB work_mem, go for it. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from copyrights, and put in standard
Bruce Momjian wrote: Remove Jan Wieck's name from copyrights, and put in standard boilerplate, with approval of author. I really don't see why or how this is an improvement. But if no one else cares about it, so be it ... I wonder what would have happened if I had stuck my name in the autovacuum.c, pg_shdepend.c or multixact.c files (wow, I did really come up with all that stuff!) I know Tom hacked extensively on all of them, so his name would also be there :-) -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Merge algorithms for large numbers of tapes
* Tom Lane ([EMAIL PROTECTED]) wrote: Luke Lonergan [EMAIL PROTECTED] writes: I would only suggest that we replace the existing algorithm with one that will work regardless of (reasonable) memory requirements. Perhaps we can agree that at least 1MB of RAM for external sorting will always be available and proceed from there? If you can sort indefinitely large amounts of data with 1MB work_mem, go for it. It seems you two are talking past each other and I'm at least slightly confused. So, I'd like to ask for a bit of clarification and perhaps that will help everyone. #1: I'm as much a fan of eliminating unnecessary code as anyone #2: There have been claims of two-pass improving things 400% #3: Supposedly two-pass requires on the order of sqrt(total) memory #4: We have planner statistics to estimate size of total #5: We have a work_mem limitation for a reason So, if we get a huge performance increase, what's wrong with: if [ sqrt(est(total)) = work_mem ]; then two-pass-sort(); else tape-sort(); fi ? If the performance isn't much different and tape-sort can do it with less memory then I don't really see any point in removing it. If the intent is to remove it and then ask for the default work_mem to be increased- I doubt going about it this way would work very well. :) Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Proposal for SYNONYMS
* elein ([EMAIL PROTECTED]) wrote: On Thu, Mar 09, 2006 at 04:42:43PM -0500, Jonah H. Harris wrote: Not a whole lot actually. If we had updateable views, I'd suggest that people change their create synonym syntax to create view. However, it would take substantially more work to implement updatable views than synonyms and the functionality of updatable views is substantially different than the use of synonyms alone. If/when updatable views are implemented, I wouldn't have a problem switching create synonym to actually create a view. Since updateable views are relatively easy to construct using rules I'm not sure an entire new syntax is necessary. They're not all that easy to construct and they require constant maintenance. If they're not maintained and the underlying table changes in some way they can end up doing the wrong thing and causing suprises. Thanks, Stephen signature.asc Description: Digital signature
Re: [HACKERS] Merge algorithms for large numbers of tapes
-Original Message- From: Stephen Frost [mailto:[EMAIL PROTECTED] Sent: Thursday, March 09, 2006 3:49 PM To: Tom Lane Cc: Luke Lonergan; Jim C. Nasby; Greg Stark; Dann Corbit; Simon Riggs; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Merge algorithms for large numbers of tapes * Tom Lane ([EMAIL PROTECTED]) wrote: Luke Lonergan [EMAIL PROTECTED] writes: I would only suggest that we replace the existing algorithm with one that will work regardless of (reasonable) memory requirements. Perhaps we can agree that at least 1MB of RAM for external sorting will always be available and proceed from there? If you can sort indefinitely large amounts of data with 1MB work_mem, go for it. It seems you two are talking past each other and I'm at least slightly confused. So, I'd like to ask for a bit of clarification and perhaps that will help everyone. #1: I'm as much a fan of eliminating unnecessary code as anyone #2: There have been claims of two-pass improving things 400% #3: Supposedly two-pass requires on the order of sqrt(total) memory Two pass does not require sqrt(total) memory. This figure is clearly wrong. Two pass will create the count of subfiles proportional to: Subfile_count = original_stream_size/sort_memory_buffer_size The merge pass requires (sizeof record * subfile_count) memory. Example: You have a 7 gigabyte table to sort and you have 100 MB sort buffer. The number of subfiles will be: 70 / 1 = 70 files Suppose that a record is 2K wide. The merge pass requires 70*2k = 143,360 bytes of RAM. Suppose that a record is 65535 bytes wide. The merge pass requires 70*65535 = 4,587,450 bytes of RAM. #4: We have planner statistics to estimate size of total #5: We have a work_mem limitation for a reason So, if we get a huge performance increase, what's wrong with: if [ sqrt(est(total)) = work_mem ]; then two-pass-sort(); else tape-sort(); fi ? If the performance isn't much different and tape-sort can do it with less memory then I don't really see any point in removing it. If the intent is to remove it and then ask for the default work_mem to be increased- I doubt going about it this way would work very well. :) Thanks, Stephen ---(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] Merge algorithms for large numbers of tapes
Stephen Frost [EMAIL PROTECTED] writes: So, if we get a huge performance increase, what's wrong with: if [ sqrt(est(total)) =3D work_mem ]; then two-pass-sort(); else tape-sort(); fi ? Possibly nothing. However, from an algorithmic point of view the CVS-tip code *is* two-pass-sort, given adequate work_mem and no requirement for random access. Further, the available profile data doesn't show any indication that the logtape.c code is eating 3/4ths of the time (at least not after we fixed the ltsReleaseBlock problem). So I basically do not believe Luke's assertion that removing logtape.c is going to produce a 4X speedup. Maybe it's time to produce some code that we can all test. 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] Merge algorithms for large numbers of tapes
Stephen, On 3/9/06 3:48 PM, Stephen Frost [EMAIL PROTECTED] wrote: So, if we get a huge performance increase, what's wrong with: if [ sqrt(est(total)) = work_mem ]; then two-pass-sort(); else tape-sort(); fi I have something similar but less complex in mind. One of the observed behaviors with the current approach is that increasing work_mem actually slows external sorting down. This is because the heapsort embedded in the replacement selection algorithm in the tape sort is not L2 cache friendly. The easiest, simplest algorithm to employ here would be to quicksort in chunks of work_mem to produce the runs, output them in a simple manner to heap files, then merge them in one pass, materializing if necessary for random access. Granted there are seek optimizations necessary to make the merge pass efficient, but these are obviously tractable in a simple manner as evidenced by others (Nyquist) and our own internal experiments. The simplicity of this is that the current approach switches from a quicksort to the polyphase tape sort when work_mem is exceeded, which involves a fairly complex chunk of code right now. In this new approach, when the sort set exceeds work_mem, we just write it out and continue. If the intent is to remove it and then ask for the default work_mem to be increased- I doubt going about it this way would work very well. :) Yep - the main question to address is whether work_mem is always sufficient to buffer the merge results in one pass, or whether degenerating to a multi-pass can be done gracefully if not. Tim Kordas here plans to work on this sometime next week using code he's already written, and I'd expect a pretty quick set of improvements through this simplified approach. - Luke ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Merge algorithms for large numbers of tapes
Tom, On 3/9/06 3:59 PM, Tom Lane [EMAIL PROTECTED] wrote: Possibly nothing. However, from an algorithmic point of view the CVS-tip code *is* two-pass-sort, given adequate work_mem and no requirement for random access. Further, the available profile data doesn't show any indication that the logtape.c code is eating 3/4ths of the time (at least not after we fixed the ltsReleaseBlock problem). So I basically do not believe Luke's assertion that removing logtape.c is going to produce a 4X speedup. Maybe it's time to produce some code that we can all test. Let's be fair - I've never asserted that logtape.c is solely responsible for the performance. - Luke ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Merge algorithms for large numbers of tapes
Dann, On 3/9/06 3:56 PM, Dann Corbit [EMAIL PROTECTED] wrote: Two pass does not require sqrt(total) memory. This figure is clearly wrong. Clearly you haven't read the paper I posted previously in this thread from 1986 written by Jim Grey at Tandem. - Luke ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] Proposal for SYNONYMS
On Thu, 9 Mar 2006, Tom Lane wrote: Stephan Szabo [EMAIL PROTECTED] writes: On Thu, 9 Mar 2006, Josh Berkus wrote: 2) For my comprehension, what's the difference between a SYNONYM and a single-object (possibly updatable) view? I think with the plan as described, the permissions handling is slightly different from how we handle views. As I understood the synonym plan, a person with select on the synonym but not on the referenced table wouldn't be able to select through the synonym, while if the view was created by someone with select a person with select on the view could select through the view. I was under the impression that privileges on the synonym wouldn't mean anything at all, with the exception that we'd track its ownership to determine who is allowed to drop the synonym. The point about views is a good one. I don't buy the argument that we should do synonyms instead of updatable views because it's easier. We *will* do updatable views at some point because (a) the spec requires it and (b) it's clearly useful. I'm not eager to be stuck with synonyms forever because somebody thought they could implement one and not the other. Well, the permissions handling would still be different between a view and a synonym AFAICS even if we dropped separate permissions on synonyms, so I don't think they're drop in replacements for each other even after updatable views. ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal for SYNONYMS
Stephan Szabo [EMAIL PROTECTED] writes: Well, the permissions handling would still be different between a view and a synonym AFAICS even if we dropped separate permissions on synonyms, so I don't think they're drop in replacements for each other even after updatable views. Agreed, but given the fact that we seem to be inventing permissions behavior for synonyms on the spur of the moment, I'm not convinced that there's anything there that anyone should put great credence in. The permissions behavior for views is at least standardized ... 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] Coverity Open Source Defect Scan of PostgreSQL
On 3/8/06, Josh Berkus josh ( at ) agliodbs ( dot ) com wrote: Actually, I thougth that Neil/eDB did this with their copy. Is there any way to get a copy of that training configuration? Just to jump in on this thread, we can absolutely configure elog -- if you have the config already, great. If not, if you can just send me the prototype/macro expansion for 'elog' and the constant values that are passed in the case where it exits, I'll add that config. Thanks! -ben ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] Proposal for SYNONYMS
Tom, (BTW, there was some work being done on updatable views, but I think it's stalled. I suspect the reason is that our current rule system is just too odd to support updatable views reasonably. I've been wondering if an implementation based on allowing triggers on views would be any more manageable.) Eh? I thought that it was just syntatic sugar that was missing. I've built lots of updatable views manually; I don't see what's difficult about it. -- --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] Proposal for SYNONYMS
Josh Berkus josh@agliodbs.com writes: Eh? I thought that it was just syntatic sugar that was missing. I've built lots of updatable views manually; I don't see what's difficult about it. I think you'll find that corner cases like inserts involving nextval() don't work real well with a rule-based updatable view. But perhaps I'm just scarred by the many complaints we've had about rules. With a plain unconditional DO INSTEAD rule it might be OK ... regards, tom lane ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from copyrights, and put in standard
Alvaro Herrera [EMAIL PROTECTED] writes: I wonder what would have happened if I had stuck my name in the autovacuum.c, pg_shdepend.c or multixact.c files We would have asked you for permission to change it to the standard project copyright. The plpgsql and pltcl files date from a time when we weren't paying much attention to having a consistent copyright notice on all parts of the source distribution, but now we are. Seeing that now you're working for a company that depends on the ability to redistribute the PG code commercially, I would think you'd be all for making sure that the legalities are nicely lined up. Do you really want to dig through the source tree at every release to see whether you can redistribute all of it? regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from copyrights,
Seeing that now you're working for a company that depends on the ability to redistribute the PG code commercially, I would think you'd be all for making sure that the legalities are nicely lined up. Do you really want to dig through the source tree at every release to see whether you can redistribute all of it? I am not sure, but I think that Alvaro's point is the copyright doesn't matter in this instance. It is the license that does. I can't read Alvaro's mind though :). It is very good to keep everything consistent. Sincerely, Joshua D. Drake -- 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 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from copyrights, and put in standard
Joshua D. Drake [EMAIL PROTECTED] writes: I am not sure, but I think that Alvaro's point is the copyright doesn't matter in this instance. It is the license that does. Certainly, but if the file says Copyright PostgreSQL Global Development Group then it's reasonable to assume that the intended license is the one in the top COPYRIGHT file. If the file says copyright someone else then this requires a bit of a leap of faith. If the file actually contains its own license language (as Jan's files did till just now) then that's unquestionably an independent license that you have to pay attention to if you're redistributing. It is very good to keep everything consistent. Yup, that's all we're after. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from copyrights, and put in standard
On Thursday 09 March 2006 20:16, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
I am not sure, but I think that Alvaro's point is the copyright
doesn't matter in this instance. It is the license that does.
Certainly, but if the file says Copyright PostgreSQL Global Development
Group then it's reasonable to assume that the intended license is the
one in the top COPYRIGHT file. If the file says copyright someone else
then this requires a bit of a leap of faith. If the file actually
contains its own license language (as Jan's files did till just now)
then that's unquestionably an independent license that you have to pay
attention to if you're redistributing.
It is very good to keep everything consistent.
Yup, that's all we're after.
It would be very good if it wasn't likely to cause more legal trouble than it
will help. Removing copyrights from actual people to be replaced with a
non-existent legal entity might be construed as eliminating any copyright
claim at all. Even if you could get the global development group recognized
legally as the copyright holder, you've only consolidated things for someone
to attempt to gain ownership of the code.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from copyrights,
Robert Treat wrote: On Thursday 09 March 2006 20:16, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: I am not sure, but I think that Alvaro's point is the copyright doesn't matter in this instance. It is the license that does. Certainly, but if the file says Copyright PostgreSQL Global Development Group then it's reasonable to assume that the intended license is the one in the top COPYRIGHT file. If the file says copyright someone else then this requires a bit of a leap of faith. If the file actually contains its own license language (as Jan's files did till just now) then that's unquestionably an independent license that you have to pay attention to if you're redistributing. It is very good to keep everything consistent. Yup, that's all we're after. It would be very good if it wasn't likely to cause more legal trouble than it will help. Removing copyrights from actual people to be replaced with a non-existent legal entity might be construed as eliminating any copyright claim at all. Even if you could get the global development group recognized legally as the copyright holder, you've only consolidated things for someone to attempt to gain ownership of the code. With the BSD license, there really isn't any restriction to enforce, so the copyright owner is pretty meaningless. -- 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
Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from
He does make a point ... if there is only one copyright holder, even if
right now its a non-entity, if someone like Oracle came along, *created* a
legal entity called 'The PostgreSQL Global Development Group', they could,
in theory, change the License wihtout needing to get approval from
current/past contributors ...
by retaining accreditation/copyright for those contributing the code, like
other projects do do, then changing the license becomes that much more
difficult ... no?
Example, wu-ftpd:
/
Copyright (c) 1999,2000 WU-FTPD Development Group.
All rights reserved.
Portions Copyright (c) 1980, 1985, 1988, 1989, 1990, 1991, 1993, 1994
The Regents of the University of California.
Portions Copyright (c) 1993, 1994 Washington University in Saint Louis.
Portions Copyright (c) 1996, 1998 Berkeley Software Design, Inc.
Portions Copyright (c) 1989 Massachusetts Institute of Technology.
Portions Copyright (c) 1998 Sendmail, Inc.
Portions Copyright (c) 1983, 1995, 1996, 1997 Eric P. Allman.
Portions Copyright (c) 1997 by Stan Barber.
Portions Copyright (c) 1997 by Kent Landfield.
Portions Copyright (c) 1991, 1992, 1993, 1994, 1995, 1996, 1997
Free Software Foundation, Inc.
Use and distribution of this software and its source code are governed
by the terms and conditions of the WU-FTPD Software License (LICENSE).
If you did not receive a copy of the license, it may be obtained online
at http://www.wu-ftpd.org/license.html.
$Id: extensions.c,v 1.48 2000/07/01 18:17:38 wuftpd Exp $
/
On Thu, 9 Mar 2006, Robert Treat wrote:
On Thursday 09 March 2006 20:16, Tom Lane wrote:
Joshua D. Drake [EMAIL PROTECTED] writes:
I am not sure, but I think that Alvaro's point is the copyright
doesn't matter in this instance. It is the license that does.
Certainly, but if the file says Copyright PostgreSQL Global Development
Group then it's reasonable to assume that the intended license is the
one in the top COPYRIGHT file. If the file says copyright someone else
then this requires a bit of a leap of faith. If the file actually
contains its own license language (as Jan's files did till just now)
then that's unquestionably an independent license that you have to pay
attention to if you're redistributing.
It is very good to keep everything consistent.
Yup, that's all we're after.
It would be very good if it wasn't likely to cause more legal trouble than it
will help. Removing copyrights from actual people to be replaced with a
non-existent legal entity might be construed as eliminating any copyright
claim at all. Even if you could get the global development group recognized
legally as the copyright holder, you've only consolidated things for someone
to attempt to gain ownership of the code.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 6: explain analyze is your friend
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---(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] [COMMITTERS] pgsql: Remove Jan Wieck's name from
On Thu, 9 Mar 2006, Bruce Momjian wrote: With the BSD license, there really isn't any restriction to enforce, so the copyright owner is pretty meaningless. if nobody owns the code, then who has to be consulted to change the license? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 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
Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from
At 9:18 PM -0500 3/9/06, Bruce Momjian wrote: Robert Treat wrote: On Thursday 09 March 2006 20:16, Tom Lane wrote: Joshua D. Drake [EMAIL PROTECTED] writes: I am not sure, but I think that Alvaro's point is the copyright doesn't matter in this instance. It is the license that does. Certainly, but if the file says Copyright PostgreSQL Global Development Group then it's reasonable to assume that the intended license is the one in the top COPYRIGHT file. If the file says copyright someone else then this requires a bit of a leap of faith. If the file actually contains its own license language (as Jan's files did till just now) then that's unquestionably an independent license that you have to pay attention to if you're redistributing. It is very good to keep everything consistent. Yup, that's all we're after. It would be very good if it wasn't likely to cause more legal trouble than it will help. Removing copyrights from actual people to be replaced with a non-existent legal entity might be construed as eliminating any copyright claim at all. Even if you could get the global development group recognized legally as the copyright holder, you've only consolidated things for someone to attempt to gain ownership of the code. With the BSD license, there really isn't any restriction to enforce, so the copyright owner is pretty meaningless. IANAL, but as I understand things, it's not possible to disclaim ownership of something. That's why the BSD license is preferable to public domain. In most legal jurisdictions, liability (for whatever) belongs to the copyright holder. By adding a license, particularly one as liberal as the BSD license, you're setting rules for how the code can be used, _and those rules can disclaim liability_. Essentially, if you take responsibility for something, you can legally insist that others use it responsibly (and if they don't, they broke your rules so it's not your fault.) Again, IANAL, but my $0.02 would be that copyright always stay with some legal entity, either the individual authors, or some actual holding company. Distributed individual copyrights (like the WU-FTPD example) seem to provide the most protection for preserving the license status quo, since everyone on the list would have to agree to change it. OTOH, an LLC or similar entity can shield individual authors from legal liability. (Though the license itself might be sufficient.) -pmb ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck`s name from copyrights,
Greg Sabino Mullane wrote: [ There is text before PGP section. ] -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I think everyone realizes at this point that the PGDG is not an official legal entity, but do we at least have a modern statement from Core as to what it is unofficially? In other words, the PostgreSQL Global Development Group is composed of My two cents: keep the individual copyrights in, or have each person sign a document transferring ownership to some other entity. (Just want to point out that MySQL has chosen the second option. ;) MySQL had to because they sell commercial versions that are non-GPL. -- 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
Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from
On Thu, 9 Mar 2006, Bruce Momjian wrote: Marc G. Fournier wrote: On Thu, 9 Mar 2006, Bruce Momjian wrote: With the BSD license, there really isn't any restriction to enforce, so the copyright owner is pretty meaningless. if nobody owns the code, then who has to be consulted to change the license? You can't. Berkeley keeps the license, and we add ourselves to it. If someone else comes along, they can copyright it and add restrictions to their version. 'k, but what is wrong with Portions copyright by ... added to the appropriate files? Why is that A Bad Thing? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] Updateable views was:(Re: [HACKERS] Proposal for SYNONYMS)
On 3/9/06, Tom Lane [EMAIL PROTECTED] wrote: Josh Berkus josh@agliodbs.com writes: Eh? I thought that it was just syntatic sugar that was missing. I've built lots of updatable views manually; I don't see what's difficult about it. I think you'll find that corner cases like inserts involving nextval() don't work real well with a rule-based updatable view. But perhaps I'm just scarred by the many complaints we've had about rules. With a plain unconditional DO INSTEAD rule it might be OK ... regards, tom lane the last time i talk with Bernd Helmle, he was preparing the code to send to patches for discussion... that was two months ago... the current code had problems with casts and i think with domains too... i will contact with Bernd to know if he did some more work, if not i can send to patches the latest path he sent me... -- regards, Jaime Casanova What they (MySQL) lose in usability, they gain back in benchmarks, and that's all that matters: getting the wrong answer really fast. Randal L. Schwartz ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from
Marc G. Fournier wrote: On Thu, 9 Mar 2006, Bruce Momjian wrote: Marc G. Fournier wrote: On Thu, 9 Mar 2006, Bruce Momjian wrote: With the BSD license, there really isn't any restriction to enforce, so the copyright owner is pretty meaningless. if nobody owns the code, then who has to be consulted to change the license? You can't. Berkeley keeps the license, and we add ourselves to it. If someone else comes along, they can copyright it and add restrictions to their version. 'k, but what is wrong with Portions copyright by ... added to the appropriate files? Why is that A Bad Thing? Nothing. I think it is good. -- 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] [COMMITTERS] pgsql: Remove Jan Wieck's name from
You can't. Berkeley keeps the license, and we add ourselves to it. If someone else comes along, they can copyright it and add restrictions to their version. 'k, but what is wrong with Portions copyright by ... added to the appropriate files? Why is that A Bad Thing? It becomes an issue should the license ever become contested. Sincerely, Joshua D. Drake Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 -- 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 5: don't forget to increase your free space map settings
Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from
Marc G. Fournier [EMAIL PROTECTED] writes: 'k, but what is wrong with Portions copyright by ... added to the appropriate files? Why is that A Bad Thing? I wouldn't object to Portions copyright Joe Blow in addition to the PGDG copyright notice. The big problem with the way that the plpgsql and pltcl files stood was that they also had their own license notices, which while generally BSD-like were not exactly the same as the top COPYRIGHT file. That I think is a seriously bad idea. We ought to have one and only one set of license terms for everything in the core distribution. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from
On Fri, 10 Mar 2006, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: 'k, but what is wrong with Portions copyright by ... added to the appropriate files? Why is that A Bad Thing? I wouldn't object to Portions copyright Joe Blow in addition to the PGDG copyright notice. The big problem with the way that the plpgsql and pltcl files stood was that they also had their own license notices, which while generally BSD-like were not exactly the same as the top COPYRIGHT file. That I think is a seriously bad idea. We ought to have one and only one set of license terms for everything in the core distribution. re: license ... agreed Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] Where Can I Find The Code Segment For WAL Control?
I am now trying to develop the PG to support real-time backup.My architecture is somehow similar to the Database Mirroring technology of SQL Server 2005.The server end of the system is consisted of two DB servers one is the Principal server,the other is the Mirror server.whenever the Principal flushes its log buffer to the local log file,it must send the content of its buffer to the Mirror simultaneously.After the mirror receives the buffer,it write to its own log file and send a response message to the Principal,then the Mirror redo/undo its log.By this way, we can guarantee the database instances of the two servers identical. But now I encounter a problem.I don't know where the functions to control log buffer are.Which code segment may I refer to? I have just participated the PG project for a short time,and I will appreciate your help very much! Look forward to you all! Charlie Wang ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
