Re: [HACKERS] Block-level CRC checks
CRC-checks will help to detect corrupt data. my question: WHAT should happen when corrupted data is detected? a) PostgreSQL can end with some paniccode b) a log can be written, with some rather high level a) has the benefit that it surely will be noticed. Which is a real benefet, as I suppose that many users of PostgreSQL on the low end do not have dedicated DBA-Admins who read the *.log every day b) has the benefit that work goes on BUT: What can somebody do AFTER PostgreSQL has detected "data is corrupted, CRC error in block " ? My first thought of action would be: get new drive, pg_dump_all to save place, install new drive, pg_restore BUT: how will pg_dump_all be enabled? As PostgreSQL must be forced to accept the corrupted data to do a pg_dump... Next step: for huge databases it is tempting to not pg_dump, but filecopy; with shut down database or pg_backup() etc. What way can that be supported while data is corrupted? Please do not misunderstand my question ... I really look forward to get this kind of information; especially since corrupted data on hard drives is an early sign of BIG trouble to come. I am just asking to start thinking about "what do after corruption has been detected" Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - EuroPython 2009 will take place in Birmingham - Stay tuned! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Cool hack with recursive queries
1st) it turns out PostgreSQL allows code that is more compact than MSQL: 19 lines instead of 46 lines 2nd) now there will be a really compelling reason for DBAs worldwide to upgrade to 8.4; after release everyone without Mandelbrot in SQL is just a lame noob 3rd) maybe THAT could be the final straw to argue against MySQL: "But it cannot do Mandelbrot, so it is not l33t" It's easier then to argue ACID and stuff. -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - EuroPython 2009 will take place in Birmingham - Stay tuned! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Packages in oracle Style
Joe and all, > The below listed tarball is out of date at this point, but I have updated > code laying around if someone really wanted it: > http://www.joeconway.com/sessfunc.tar.gz > I've used variations of this over the years on several projects. is someone able and willing to provide this tarball compiled to a PostgreSQL-8.3.1 usable win32-dll ? ATM I am using session variables in pure PL/SQL via temp tables. ..:) Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pidgeon - EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS]
Yuan, Welcome! To get you going till someone of quite higher blessing then me can answer, some helpfull links: http://www.postgresql.org/developer/ on this page specially the following sections: http://wiki.postgresql.org/wiki/Developer_FAQ if you are looking for a concrete job to do http://www.postgresql.org/docs/faqs.TODO.html Subscribing to -hackers and saying "hello" was also a wise thing to do! Best wishes, Harald On Thu, Jun 26, 2008 at 01:42, yuan fang <[EMAIL PROTECTED]> wrote: > i am studying the source code of postgresql and want to become a developer > of it.What should i do? > thanks > > > Explore the seven wonders of the world Learn more! -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pidgeon - EuroPython 2008 will take place in Vilnius, Lithuania - Stay tuned! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] pg_upgrade project status
> I think it's fairly easy to install Perl on Windows actually. It > doesn't sound too onerous a requirement if you want in-place upgrade; > actually it looks a very reasonable one. > > Much more reasonable than Korn shell in any case (or any shell for that > matter; I think anything is going to be more of a potentially painful > platform dependency than Perl). > May I humbly recommend to rewrite in Python? That should be as difficult / easy as PERL, AND there is a very robust py2exe implementation, which allows to create a single .exe file which contains everything. Python is present on all Linux, Windows users are totally comfortable with .exe files. Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - EuroPython 2009 will take place in Birmingham - Stay tuned! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] effective_cache_size less than shared_buffers
Greg, > > Well we won't eliminate any problems unless we actually override the > effective_cache_size setting by clipping it to shared_buffers. I don't > really see much of a problem doing that. The only case where that > would annoy someone was if they're intentionally understating > effective_cache_size to push the planner into avoiding nested loops > and I doin't think it's a powerful enough knob to be very likely used > that way. > My experience from PostgreSQL on Windows: effective_cache_size should reflect the value of "system cache" from task manager. shared_buffers (on windows) should be rather small. My real-workload-tests (no benchmarks, real usage of DB-Server) showed that big shared buffers on Windows have a negative effect on PostgreSQL performance. I have found no explanation WHY it is this way. Harald -- GHUM Harald Massa persuadere et programmare Harald Armin Massa Spielberger Straße 49 70435 Stuttgart 0173/9409607 no fx, no carrier pigeon - EuroPython 2009 will take place in Birmingham - Stay tuned!
Re: [HACKERS] [PATCHES] Patch for UUID datatype (beta)
> Anyone who thinks UUIDs are guaranteed unique has been drinking too much> of the kool-aid. > Identifier uniqueness considerations:> This document specifies three algorithms to generate UUIDs: the> first leverages the unique values of 802 MAC addresses to > guarantee uniqueness, the second uses pseudo-random number> generators, and the third uses cryptographic hashing and> application-provided text strings. As a result, the UUIDs> generated according to the mechanisms here will be unique from all > other UUIDs that have been or will be assigned.That is a quote from the ftp://ftp.rfc-editor.org/in-notes/rfc4122.txt And to quote ITU-T """If generated according to one of the mechanisms defined in ITU-T Rec. X.667 | ISO/IEC 9834-8, a UUID is either guaranteed to be different from all other UUIDs generated before 3603 A.D., or is extremely likely to be different (depending on the mechanism chosen). The UUID generation algorithm specified in this standard supports very high allocation rates: 10 million per second per machine if necessary, so UUIDs can also be used as transaction IDs."""They also talk about a "guaranteed differentness" - and as much as I understand, they are Unique as long as the MAC-Adresses of the Network-Cards are unique, and fall back to "extremly likely" when there is no network card present. I would really like PostgreSQL to include an uuid-generation function crafted along the recommendations in rfc4122 or ISO/IEC 9834-8; so those UUIDs have a "ISO/IEC-defined uniqueness" or at least a "ISO/IEC-defined extreme likelyness to be unique" As of now there are at least 3 implementations for UUID creation for PostgreSQL in the wild; as much as I understand is that "UUIDs created by the same algorithm" are much more likely to be unique to each other then UUIDs created by different algorithms. Harald-- GHUM Harald Massapersuadere et programmareHarald Armin MassaReinsburgstraße 202b70197 Stuttgart0173/9409607-Let's set so double the killer delete select all.
Re: [HACKERS] [PATCHES] Patch for UUID datatype (beta)
Mark,A model that intended to try and guarantee uniqueness would provide aUUID generation service for the entire host, that was not specific to any application, or database, possibly accessible via the loopbackaddress. It would ensure that at any given time, either the time isnew, or the sequence is new for the time. If computer time ever wentbackwards, it could keep the last time issued persistent, and increment from this point forward through the clock sequence valuesuntil real time catches up. An alternative would be along the lines ofa /dev/uuid device, that like /dev/random, would be responsible foroutputting unique uuid values for the system. Who does this? Probably nobody. I'm tempted to implement it, though, for my uses. :-)That is an excellent summary. There is just one wrong assumption in it:>Probably nobody. Within win32 there is an API call, which provides you with an GUID / UUID with to my knowledge exactly the features you are describing. win32 is installed on some computers. So for PostgreSQL on win32 the new_guid() you describe in detail would be quite simple to implement: a call to CoCreateGuid.The challenging part is: I use PostgreSQL in a mixed environment. And Linux i.e. does not provide CoCreateGuid. That's why I am voting to have it in PostgreSQL :) Harald-- GHUM Harald Massapersuadere et programmareHarald Armin MassaReinsburgstraße 202b70197 Stuttgart0173/9409607-Let's set so double the killer delete select all.
Re: [HACKERS] [GENERAL] Private email requests
Bruce, list, I translated that part to german, I know the source is strong in Germany - maybe it can be a helpfull addition - even if most speak English, they are even more happy to read sth. in German. Harald Due to time constraints, I do not directly answer general PostgreSQLquestions. For assistance, please join the appropriate mailing list and post your question:http://www.postgresql.org/communityYou can also try the #postgresql IRC channel on irc.freenode.net . Seethe PostgreSQL FAQ for more information. Leider ist es mir wegen Zeitknappheit nicht möglich, persönlich auf PostgreSQL-Fragen zu antworten. Unterstützung findet man durch Mitgliedschaft in der passenden Mailing-Liste; dort sind Fragen willkommen: http://www.postgresql.org/community Eine hilfreiche Ressource ist auch der #postgresql IRC-Channel auf dem Server irc.freenode.net. In der PostgreSQL FAQ gibt es mehr Informationen. Bitte beachten: Das Gros der Kommunikation erfolgt in Englisch. -- GHUM Harald Massapersuasion python postgresqlHarald Armin MassaReinsburgstraße 202b70197 Stuttgart0173/9409607
