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

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.

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

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 iss

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 own

[HACKERS] Updateable views was:(Re: [HACKERS] Proposal for SYNONYMS)

On 3/9/06, Tom Lane <[EMAIL PROTECTED]> wrote: > Josh Berkus 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 n

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 li

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

Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from

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. Berkele

Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck's name from

> 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

Re: [HACKERS] [COMMITTERS] pgsql: Remove Jan Wieck`s name from copyrights, and put in standard

-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

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 d

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 Service

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 curr

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

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 Dev

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 in

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 redist

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

Re: [HACKERS] Proposal for SYNONYMS

Josh Berkus 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 updatabl

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

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

On 3/8/06, Josh Berkus 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

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 gi

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 permiss

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 --

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 t

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 obse

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

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

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

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 wil

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 autov

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

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 > referen

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 t

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 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

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 w

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 t

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

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 e

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

Re: [HACKERS] Proposal for SYNONYMS

On 3/9/06, Josh Berkus 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 c

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? -- --Jos

Re: [HACKERS] PostgreSQL Anniversary Summit, Call for Contributions

On Thu, 9 Mar 2006 16:18:43 -0500 "D'Arcy J.M. Cain" 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

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 ca

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()

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 is

Re: [HACKERS] Coverity Open Source Defect Scan of PostgreSQL

On Thu, 9 Mar 2006, Bruce Momjian wrote: 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__,

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 , I've put up some information about this. I'll be expanding those pages as things mov

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 >>28735

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 w

Re: [HACKERS] Proposal for SYNONYMS

On Thu, 9 Mar 2006, Stephen Frost wrote: > * 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 all

Re: [HACKERS] 8.2 hold queue [MB Chars' Case Conversion]

Hi, On Mar 08 04:08, Bruce Momjian wrote: > I have applied all the patches in the patch queue, and am starting to > look at the patches_hold queue, which are patches submitted after the > feature freeze. Related with BUG #1931: ILIKE and LIKE fails on Turkish locale Case Conversion Fix for M

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 state

Re: [HACKERS] Merge algorithms for large numbers of "tapes"

"Luke Lonergan" <[EMAIL PROTECTED]> writes: > 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,

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 tuplesor

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 refere

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 syno

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 add

Re: [HACKERS] Proposal for SYNONYMS

SYNONYMS are symbolinks in database? CREATE SYNONYMS bar FOR foo; DROP TABLE foo; Now bar point to an invalid object. Or should we let DROP TABLE foo CASCADE; to drop the SYNONYMS depended on the table? Also need to add \d support for psql. Regards, William ZHANG --

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

Re: [HACKERS] problem with large maintenance_work_mem settings and

Simon Riggs wrote: On Wed, 2006-03-08 at 10:45 -0500, Tom Lane wrote: Stefan Kaltenbrunner <[EMAIL PROTECTED]> writes: CREATE INDEX on a 1,8B row table (5 int columns - index created on the first row about 300M distinct values): before: 11h 51min after: 3h 11min(!) Cool. Does it seem to

[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.

Re: [HACKERS] Merge algorithms for large numbers of "tapes"

On Wed, Mar 08, 2006 at 10:20:08PM -0500, Greg Stark wrote: > > For that to be of any use, wouldn't you need to use only as many tapes > > as spindles/2? Otherwise you're still trying to read and write from the > > same set of drives, which means you're probably doing a lot of seeking. > > Or do th

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 i

Re: [HACKERS] [COMMITTERS] pgsql: Remove Christof Petig copyright on include file,

Martijn van Oosterhout 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 contribute

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__,

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

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), (ele

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 f

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 > operati