Re: [HACKERS] View definition formatting
-Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: 01 April 2003 20:59 To: Robert Treat Cc: Peter Eisentraut; Dave Page; [EMAIL PROTECTED] Subject: Re: [HACKERS] View definition formatting We could make variants of pg_get_ruledef etc. that pretty-print, while leaving the existing behavior alone, I suppose. Hacking those functions never crossed my mind, but it would certainly do what I require, and is probably more within the scope of things I could do myself. *If* I get time and can figure it out, how would people feel about pg_get_pp_viewdef(oid) etc? Regards, Dave. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PostgreSQL and SOAP, suggestions?
mlw kirjutas T, 01.04.2003 kell 15:29: Hannu Krosing wrote: [EMAIL PROTECTED] kirjutas E, 31.03.2003 kell 19:52: Actually, as far as I am aware, the header is for metadata, i.e. it is the place to describe the data being returned. Did you read the SOAP spec ? yes ??? What you have come up with _is_not_ a SOAP v1.1 message at all. It does use some elements with similar names but from different namespace. the SOAP Envelope, Header and Body elemants must be from namespace http://schemas.xmlsoap.org/soap/envelope/ Per section 3 paragraph 2 of SOAP spec a conforming SOAP processor MUST discard a message that has incorrect namespace. ?xml version = 1.0? mwssql:Envelope xmlns:mwssql=http://www.mohawksoft.com/mwssql/envelope; mwssql:Header The SOAP-ENV:Header is a generic mechanism for adding features to a SOAP message in a decentralized manner without prior agreement between the communicating parties. SOAP defines a few attributes that can be used to indicate who should deal with a feature and whether it is optional or mandatory (see section 4.2). The SOAP-ENV:Body is a container for mandatory information intended for the ultimate recipient of the message (see section 4.3). SOAP defines one element for the body, which is the Fault element used for reporting errors. The Header element is encoded as the first immediate child element of the SOAP Envelope XML element. All immediate child elements of the Header element are called header entries. The encoding rules for header entries are as follows: 1. A header entry is identified by its fully qualified element name, which consists of the namespace URI and the local name. All immediate child elements of the SOAP Header element MUST be namespace-qualified. ... An example is a header with an element identifier of Transaction, a mustUnderstand value of 1, and a value of 5. This would be encoded as follows: SOAP-ENV:Header t:Transaction xmlns:t=some-URI SOAP-ENV:mustUnderstand=1 5 /t:Transaction /SOAP-ENV:Header exec:sqlupdate cgrpairs set ratio=0 where srcitem=100098670/exec:sql exec:affected2657/exec:affected qry:sqlselect * from ztitles limit 2/qry:sql qry:ROWSET qry:ROW columns=28 where are namespaces exec:, qry: abd t: defined ? Hannu ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL and SOAP, suggestions?
Hannu Krosing wrote: mlw kirjutas T, 01.04.2003 kell 15:29: Hannu Krosing wrote: [EMAIL PROTECTED] kirjutas E, 31.03.2003 kell 19:52: Actually, as far as I am aware, the header is for metadata, i.e. it is the place to describe the data being returned. Did you read the SOAP spec ? yes ??? What you have come up with _is_not_ a SOAP v1.1 message at all. It does use some elements with similar names but from different namespace. the SOAP Envelope, Header and Body elemants must be from namespace http://schemas.xmlsoap.org/soap/envelope/ [snip] Hmm, I read SHOULD and MAY in the spec, assuming that it was not MUST are you saying it is invalid if I do not use the SOAP URIs for the name spaces? If so, no big deal, I'll change them. As for defining the namespaces, yea that's easy enough, just tack on an attribute. I still don't see where putting the field definitions in the soap header is an invalid use of that space. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] mariposa
hi, does anybody know anything about mariposa (http://s2k-ftp.cs.berkeley.edu:8000/mariposa/index.html)? why did they stop the project? is there anywhere an intel compatible version? i'm interested in such a system and thinking about developing something like this. thanks, moritz -- ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] updateable cursors visibility
On Mon, 31 Mar 2003, Peter Eisentraut wrote: Tom Lane writes: Serializable or not, there is a good case for saying that cursors don't see changes made after they are opened, period. No one disputes that insensitive cursors are a valid concept. But this discussion is about updating such a cursor. What view of the data would such a cursor represent after an update? What about this example: CREATE TABLE foo (a int PRIMARY KEY); INSERT INTO foo VALUES (1); ... much later ... BEGIN; DECLARE test INSENSITIVE CURSOR FOR UPDATE FOR SELECT a FROM foo; INSERT INTO foo VALUES (2); FETCH NEXT FROM test; UPDATE foo SET a = 2 WHERE CURRENT OF test; ... COMMIT; Does the UPDATE catch the constraint violation? Good point. There is no direct reference to this condition in SQL99 -- as far as I can tell. We do have this however in SQL99 14.9 General Rules: 4) The extent to which an SQL-implementation may disallow independent changes that are not significant is implementation-defined Where 'independent' means a change not made by update statement: positioned or delete statement: positioned and 'significant' means that, had the change been made before the cursor was opened, the underlying table of the cursor would be different in some respect. If the cursor is insensitive, then significant changes are not visible by the cursor. So, for insensitive cursors we could disallow changes independent of the cursor. I don't think this is useful but it suggests that sensitive cursors should allow independent changes and that these should be visible to the cursor. But that isn't really the issue. We also get the following in SQL99 update statement: positioned General Rules: 8) If, while CR is open, an object row has been marked for deletion by any delete statement: searched, marked for deletion by any delete statement: positioned that identifies any cursor other than CR, updated by any update statement: searched, or updated by any update statement: positioned that identifies any cursor other than CR, then a completion condition is raised: warning cursor operation conflict. But this just muddies the waters. I think it comes down to this: insensitive cursors should behave as they currently do. If they are used by update/delete statement: positioned, they still need to adhere to the normal visibility of UPDATE or DELETE -- which is what, I think, Bruce originally proposed. So, I would like to go ahead and implement update/delete statement: positioned (regardless of the nature of visibility we decide on). Bruce's proposal basically sees the tid of the last FETCH'd or MOVE'd to tuple stored in the Portal structure for that cursor. This shouldn't be hard since DoRelativeFetch() calls ExecutorRun() for non-holdable cursors, which returns the last TupleTableSlot returned, which gives access to the tid of the last FETCH'd tuple. Likewise, DoRelativeStoreFetch() seems to have direct access to the data required, covering holdable cursors. This means that when we handle an update/delete statement: positioned, we could either do a rough hack and look up the Portal for the named cursor inside of the parse and analyze code and fill out a where clause Node to the effect of 'ctid = saved tid'. Alternatively, we could just register that it is a positioned update/delete and look it up somewhere else: planner, executor...? Regardless of which, we could insert a special case in ExecutePlan() (or somewhere more appropriate?) to test that the tuple returned from the lower level ExecTidScan() still satisifies the cursor query. It should be sufficient to use HeapTupleSatisfies() or some of the logic there in to do this. If all goes well, then the update/delete will succeed. Comments? Gavin ---(end of broadcast)--- TIP 3: 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] updateable cursors visibility
Gavin Sherry [EMAIL PROTECTED] writes: Regardless of which, we could insert a special case in ExecutePlan() (or somewhere more appropriate?) to test that the tuple returned from the lower level ExecTidScan() still satisifies the cursor query. It should be sufficient to use HeapTupleSatisfies() or some of the logic there in to do this. I don't think so; you'll need to use EvalPlanQual. This is not different from the situation where a regular UPDATE finds a tuple that is not the latest version of its row. Should I point out that we already have semantics for that behavior, and they depend on the serialization mode? Most of this discussion seems to completely ignore the MVCC semantics we already have for updates/deletes applied to rows that aren't current anymore. ISTM we should stick to that behavior ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] 7.3.2 make failed on AIX4.3 using native c compiler
Thanks for the replies of Tom, Bruce, Justin, and Peter regarding my posts and personal emails. Just wants to provide some updates - Summary of issues: 1. I was asked to tune a production database on client's AIX4.3.3 - it's Postgresql 7.3.1, I can vacuum full, but can't do analyze (hanging); it looks like I can run make but make check hangs (I failed to provide Tom's requests about the trace since I can't do too much on client's machine); 2. I can't reproduce on my local AIX4.3.3 ( I checked instfix -i|grep ML on both machine, the oslevel the same, patch levels are similar); 3. I can't make 7.3.2 on one of my local AIX 4.3.3 (errors posted) until we added some oslevel-10/11 patches update; on the other hand I can make 7.3.2 very clean on another local AIX 4.3.3 with oslevel-9 (another puzzle to me?) 4. I tried to make one locally and then try to install on the client's AIX, here're some lesson learned - 1) first time - after install, can't start postmaster because of Dependent module /usr/local/lib/libz.a(shr.o) could not be loaded. Member shr.o is not found in archive To solve the above problem, I've to download and install the zlib from www.bull.de not the one from freshmeat! 2) 2nd time - I can start postmaster, but can't start psql client, it requires libreadline.so (libreadline.a is not enough), I've to download the gnu-readline source from freshmeat to compile it not the one from www.bull.de!! after the above struggling, I believe the Analyze hangs problem is solved! My belief is some improvements should do in configure/make, to have a partial functioned postgresql installed on production account is not good. (Note: make should fail but not, IMHO, the good news is at least make check hangs). Hopefully this post will help some AIX users. thanks for the helps. John Liu -Original Message- From: Peter Eisentraut [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2003 3:41 PM To: John Liu Cc: [EMAIL PROTECTED] Subject: Re: [HACKERS] 7.3.2 make failed on AIX4.3 using native c compiler John Liu writes: make[4]: Leaving directory `/emrxdbs/postgresql-7.3.2/src/backend/parser' cc -O2 -qmaxmem=16384 -qsrcmsg -qlonglong -I../../../src/interfaces/libpq -I ../../../src/include -I/usr/local/include -DBINDIR=\/emrxdbs/pgsql/bin\ - c -o pg_dump.o pg_dump.c 2681 | COMMENT, deps, a This looks pretty bogus. The code in around line 2681 is ArchiveEntry(fout, oid, target, namespace, owner, COMMENT, deps, query-data, , NULL, NULL, NULL); deps is declared in the signature of the surrounding function: static void dumpComment(Archive *fout, const char *target, const char *namespace, const char *owner, const char *oid, const char *classname, int subid, const char *((*deps)[])) The declaration of ArchiveEntry() is: extern void ArchiveEntry(Archive *AHX, const char *oid, const char *tag, const char *namespace, const char *owner, const char *desc, const char *((*deps)[]), const char *defn, const char *dropStmt, const char *copyStmt, DataDumperPtr dumpFn, void *dumpArg); deps has exactly the same type in both. I wonder whether the const gets lost somewhere, perhaps due to something that configure does. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 3: 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] Dangling backends on win32 7.2.1 port (peerdirect).
TRY TEST WIN32 PORT. DATABASE GO BOOM! TRY FIX NOBODY CARE. WIN32 PORT COME OUT MANY DATABASE GO BOOM! TRY HELP GET IGNORED. JUST WANT HELP. BUG FIX? Regards, Merlin ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] optimizer cost calculation problem
On Tue, Apr 01, 2003 at 11:24:01AM -0500, Tom Lane wrote: scott.marlowe [EMAIL PROTECTED] writes: This isn't really an issue for 64 bit hardware is it? Is int 64 bits on such a machine? The ones I've dealt with chose to It was for the regression tests we did recently on a 64-bit gcc-3.2-compiled Solaris 8 binary. Piles of regression failures because int was not 32 bits. A -- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 3: 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] 7.4devel auth failed
Andreas Pflug [EMAIL PROTECTED] writes: If your kernel isn't V6 enabled, the incoming socket will be AF_INET, and no conversion is done, that's why you don't get the problem. To fix this, the [12]..[15] indices need to be reversed (for Intel). I've applied a patch to fix this, but can't try it out here for lack of any IPv6 infrastructure ... please check it. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Dangling backends on win32 7.2.1 port (peerdirect).
Merlin Moncure wrote: TRY TEST WIN32 PORT. DATABASE GO BOOM! TRY FIX NOBODY CARE. WIN32 PORT COME OUT MANY DATABASE GO BOOM! TRY HELP GET IGNORED. JUST WANT HELP. BUG FIX? Pardonne moi? What exactly did you test? If it is the PeerDirect Beta version of PostgreSQL for Windows named UltraSQL, please know that thus far there has to my knowledge not been an offical, supported release of UltraSQL yet - and since the company eliminated the group working on that port, I doubt there ever will. PeerDirect tried to contribute the Win32 port portion of their work to the open source project. The PostgreSQL global development team has not yet made any final decision if or what parts of that code will or will not become part of the regular PostgreSQL distribution. So ... YOU DO NOT USE ANYTHING OFFICIALLY SUPPORTED BY US!!! Could you therefore calm down, stop shouting, comb your hair, get the sources of the current work in progress and send in your complains/suggestions in context diff format? Have a nice day, Jan Regards, Merlin ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED] -- #==# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #== [EMAIL PROTECTED] # ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Detecting corrupted pages earlier
Kevin Brown [EMAIL PROTECTED] writes: Tom Lane wrote: Basically, one should only turn this variable on after giving up on the possibility of getting any data out of the broken page itself. It would be folly to run with it turned on as a normal setting. This statement should *definitely* go into the documentation for the option, then... Andrew Sullivan expressed concern about this, too. The thing could be made a little more failsafe if we made it impossible to set ZERO_DAMAGED_PAGES to true in postgresql.conf, or by any means other than an actual SET command --- whose impact would then be limited to the current session. This is kind of an ugly wart on the GUC mechanism, but I think not difficult to do with an assign_hook (it just has to refuse non-interactive settings). Comments? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Detecting corrupted pages earlier
On Wed, Apr 02, 2003 at 03:25:58PM -0500, Tom Lane wrote: the current session. This is kind of an ugly wart on the GUC mechanism, but I think not difficult to do with an assign_hook (it just has to refuse non-interactive settings). It may be an ugly wart, but I think it's only prudent. I'd be willing to bet a fair amount that there is a significant overlap between the population which uses Bob's Discount Hardware for 10 million row, ultra-critical databases and the population which likes to twiddle postgresql.conf settings without reading the fine manual. Those folks are going to get burned by this setting unless it is very hard to turn on. (I think the setting is an excellent idea, though, for emergency cases.) I don't usually like making servers totally idiot-proof, but I can just imagine the Slashdot conversations after 7.4 comes out (and for at least 60 or 70 years thereafter): PostgreSQL just randomly zeroes a page of data! It sucks! Use MySQL instead. It can recover from bad pages on your disk by randomly making up data for you, instead of just writing zeros. A -- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Detecting corrupted pages earlier
Tom Lane wrote: Kevin Brown [EMAIL PROTECTED] writes: Tom Lane wrote: Basically, one should only turn this variable on after giving up on the possibility of getting any data out of the broken page itself. It would be folly to run with it turned on as a normal setting. This statement should *definitely* go into the documentation for the option, then... Andrew Sullivan expressed concern about this, too. The thing could be made a little more failsafe if we made it impossible to set ZERO_DAMAGED_PAGES to true in postgresql.conf, or by any means other than an actual SET command --- whose impact would then be limited to the current session. This is kind of an ugly wart on the GUC mechanism, but I think not difficult to do with an assign_hook (it just has to refuse non-interactive settings). Hmm...I don't know that I'd want to go that far -- setting this variable could be regarded as a policy decision. Some shops may have very good reason for running with ZERO_DAMAGED_PAGES enabled all the time, but I don't know what those reasons might be. But the fact that I can't think of a good reason isn't sufficient cause to remove that as an option. I would definitely be in favor of issuing a warning (Running with ZERO_DAMAGED_PAGES enabled will cause you to lose possibly recoverable data whenever a damaged page is encountered. Be sure you know what you're doing) whenever the variable is set, whether it be at startup or during a session. -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Detecting corrupted pages earlier
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Perhaps better would be to throw a message message any time it is turned on, reminding them it should not be left on. Is that cleaner? Where are you going to throw a message to, if it's in postgresql.conf? Bleating in the postmaster log probably won't draw the attention of a user clueless enough to be trying this ;-) Perhaps. I'd bank more on the user checking the postmaster log than being clueful enough not to use this, though, since the postmaster log is pretty much a universal thing that has been around a long time while this option hasn't. Cluelessness about the use of a rather esoteric option doesn't necessarily imply total cluelessness. :-) -- Kevin Brown [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Detecting corrupted pages earlier
Andrew Sullivan [EMAIL PROTECTED] writes: On Wed, Apr 02, 2003 at 03:25:58PM -0500, Tom Lane wrote: the current session. This is kind of an ugly wart on the GUC mechanism, but I think not difficult to do with an assign_hook (it just has to refuse non-interactive settings). It may be an ugly wart, but I think it's only prudent. I'd be willing to bet a fair amount that there is a significant overlap between the population which uses Bob's Discount Hardware for 10 million row, ultra-critical databases and the population which likes to twiddle postgresql.conf settings without reading the fine manual. Those folks are going to get burned by this setting unless it is very hard to turn on. (I think the setting is an excellent idea, though, for emergency cases.) I don't usually like making servers totally idiot-proof, but I can just imagine the Slashdot conversations after 7.4 comes out (and for at least 60 or 70 years thereafter): PostgreSQL just randomly zeroes a page of data! It sucks! Use MySQL instead. It can recover from bad pages on your disk by randomly making up data for you, instead of just writing zeros. Perhaps the real answer is to use a more *descriptive* name for the variable than ZERO_DAMAGED_PAGES. Something along the lines of CLUELESS_DBA_ESCHEWS_BACKUPS, or ONLY_AN_IDIOT_SETS_THIS_VARIABLE. You don't have to read the manual to see that these variables are not to be trifled with. There are some cases where this particular feature would be useful. What needs to be done is to make the feature less dangerous to the newbie without making it less useful to the person who actually needs the functionality. Jason ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Detecting corrupted pages earlier
Kevin Brown [EMAIL PROTECTED] writes: Hmm...I don't know that I'd want to go that far -- setting this variable could be regarded as a policy decision. Some shops may have very good reason for running with ZERO_DAMAGED_PAGES enabled all the time, but I don't know what those reasons might be. I would buy this argument if I could imagine even a faintly plausible reason for doing that ... but I can't. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] TODO list problem or am I way off base?
Hey Guys, Sorry if this should go to another list, but I was looking over the TODO list for something small I could cut my teeth on and noticed you have the following listed in the TODO in the 'Source Code' section: * Add --port flag to regression tests And based on what I can tell the shell script src/test/regress/pg_regress.sh already has the ability to define the port with --port. It sets the PGPORT environment variable. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org - ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] PostgreSQL and SOAP, suggestions?
Andrew Dunstan writes: If the intention is to use field names as (local) tag names, how will you handle the case where the field name isn't a valid XML name? Of course, one could do some sort of mapping (replace illegal chars with _, for example) but then you can't be 100% certain that you haven't generated a collision, I should think. The SQL/XML draft specifies an reversible escape mechanism. Basically, when mapping an SQL identifier to an XML name you replace problematic characters with an escape sequence based on the Unicode code point, like _x2A3B_. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PostgreSQL and SOAP, suggestions?
mlw writes: That function looks great, but what happens if you need to return 1 million records? The same thing that happens with any set-returning function: memory exhaustion. I have an actual libpq program which performs a query against a server, and will stream out the XML, so the number of records has very little affect on efficiency. I think the table2xml function is great for 99% of all the queries, but for those huge resultsets, I think it may be problematic. What do you think? Clearly, my approach is not sufficient if you need to handle big result sets. But perhaps a compromise based on cursors could be designed so that large parts of the format can be managed centrally. Such as: DECLARE foo CURSOR FOR SELECT ... ; -- gives you the XML Schema for the result set SELECT xmlschema_from_cursor(foo); -- gives you ones row (row.../row) SELECT xmldata_from_cursor(foo); -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] Dangling backends on win32 7.2.1 port (peerdirect).
Jan Wieck wrote: What exactly did you test? If it is the PeerDirect Beta version of PostgreSQL for Windows named UltraSQL, please know that thus far there has to my knowledge not been an offical, supported release of UltraSQL yet - and since the company eliminated the group working on that port, I doubt there ever will. I tested the binary released version and my own compiled version. I have been trying to compile the version that is patched to the latest official release but so far I've been having trouble getting that compiled. PeerDirect tried to contribute the Win32 port portion of their work to the open source project. The PostgreSQL global development team has not yet made any final decision if or what parts of that code will or will not become part of the regular PostgreSQL distribution. So ... YOU DO NOT USE ANYTHING OFFICIALLY SUPPORTED BY US!!! Could you therefore calm down, stop shouting, comb your hair, get the sources of the current work in progress and send in your complains/suggestions in context diff format? Sorry, I didn't mean to offend. My understanding is that the UltraSQL patches are likely to go into general release when the source goes 7.4/8.0. There is at least one show-stopping bug which I believe is related to the shared memory emulation. I am almost 100% sure that the bug is in the win32 side and if still present will carry over to the latest release. I offered to help find and catch it: but before I spend the time to do that I'd like to at least know if the problem has already been addressed. I was responding to the call for capable developers to help test upcoming patch, posted on this very list about two weeks ago. I'm not asking for support but trying to help. Sorry to bother, Merlin ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] PostgreSQL and SOAP, suggestions?
mlw kirjutas K, 02.04.2003 kell 15:56: Hannu Krosing wrote: What you have come up with _is_not_ a SOAP v1.1 message at all. It does use some elements with similar names but from different namespace. the SOAP Envelope, Header and Body elemants must be from namespace http://schemas.xmlsoap.org/soap/envelope/ [snip] Hmm, I read SHOULD and MAY in the spec, assuming that it was not MUST are you saying it is invalid if I do not use the SOAP URIs for the name spaces? If so, no big deal, I'll change them. AFAICS you can _leave_out_ the namespace, but not put in another, nonconforming namespace. As for defining the namespaces, yea that's easy enough, just tack on an attribute. I still don't see where putting the field definitions in the soap header is an invalid use of that space. It is not strictly nonconforming, just not the intended use of transparently adding new info: 4.2 SOAP Header SOAP provides a flexible mechanism for extending a message in a decentralized and modular way without prior knowledge between the communicating parties. Typical examples of extensions that can be implemented as header entries are authentication, transaction management, payment etc. I.e. the intended use of *SOAP* Header is *not* defining the structure of the message but is rather something similar to e-mail (rfc822) Headers. The XML way of defining a message is using a DTD, XML-schema, Relax NG schema or somesuch, either embedded (forbidden for DTD's in SOAP) or referenced. Also for me the following: The Header element is encoded as the first immediate child element of the SOAP Envelope XML element. All immediate child elements of the Header element are called header entries. The encoding rules for header entries are as follows: 1. A header entry is identified by its fully qualified element name, which consists of the namespace URI and the local name. All immediate child elements of the SOAP Header element MUST be namespace-qualified. describes an element with a full embedded URI, not just namespace-qualified tagname, but I may be reading it wrong and the namespace could be defined at outer level. But defining namespace at the outer level is counterintuitive for cases where the header element is to be processed and removed by some SOAP intermediary. Also this seems to support *not* using Header for essensial structure definitions: 4.3.1 Relationship between SOAP Header and Body While the Header and Body are defined as independent elements, they are in fact related. The relationship between a body entry and a header entry is as follows: A body entry is semantically equivalent to a header entry intended for the default actor and with a SOAP mustUnderstand attribute with a value of 1. The default actor is indicated by not using the actor attribute (see section 4.2.2). This suggests that putting the structure definition as 1-st Body element and data as second would be equivalent to putting structure in Header - Hannu ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [HACKERS] contrib and licensing
Tom Lane wrote: mlw [EMAIL PROTECTED] writes: I know nothing in contrib should be GPL, I have no problem with that. The question is the requirement of a GPL library to build a contrib project. My SOAP/XML function will probably require my LGPL library as there is a lot of code I have written that I would need to implement it. If it won't work without your library then there's not much point in putting it into contrib. Might as well just put it in your library and distribute same as you have been doing. I'm a little put off by this attitude, are you saying there are no LGPL dependencies in PostgreSQL or /contrib? If that is a real objective, I'm surprised. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] PostgreSQL and SOAP, suggestions?
Hannu Krosing wrote: mlw kirjutas K, 02.04.2003 kell 15:56: Hannu Krosing wrote: What you have come up with _is_not_ a SOAP v1.1 message at all. It does use some elements with similar names but from different namespace. the SOAP Envelope, Header and Body elemants must be from namespace http://schemas.xmlsoap.org/soap/envelope/ [snip] Hmm, I read SHOULD and MAY in the spec, assuming that it was not MUST are you saying it is invalid if I do not use the SOAP URIs for the name spaces? If so, no big deal, I'll change them. AFAICS you can _leave_out_ the namespace, but not put in another, nonconforming namespace. [snip] I think you are interpreting the spec a bit too restrictively. The syntax is fairly rigid, but the spec has a great degree of flexibility. I agree that, syntactically, it must work through a parser, but there is lots of room to be flexible. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib and licensing
On Wed, 2 Apr 2003, mlw wrote: Tom Lane wrote: mlw [EMAIL PROTECTED] writes: I know nothing in contrib should be GPL, I have no problem with that. The question is the requirement of a GPL library to build a contrib project. My SOAP/XML function will probably require my LGPL library as there is a lot of code I have written that I would need to implement it. If it won't work without your library then there's not much point in putting it into contrib. Might as well just put it in your library and distribute same as you have been doing. I'm a little put off by this attitude, are you saying there are no LGPL dependencies in PostgreSQL or /contrib? In fact, yes ... or, at least, if there are any left in /contrib, its only because we haven't moved them to gborg yet ... If that is a real objective, I'm surprised. The base source tree has always been as BSD pure as we can make it ... its never been kept a secret ... ---(end of broadcast)--- TIP 3: 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] contrib and licensing
On Wed, 2 Apr 2003, mlw wrote: Tom Lane wrote: mlw [EMAIL PROTECTED] writes: I know nothing in contrib should be GPL, I have no problem with that. The question is the requirement of a GPL library to build a contrib project. My SOAP/XML function will probably require my LGPL library as there is a lot of code I have written that I would need to implement it. If it won't work without your library then there's not much point in putting it into contrib. Might as well just put it in your library and distribute same as you have been doing. I'm a little put off by this attitude, are you saying there are no LGPL dependencies in PostgreSQL or /contrib? If that is a real objective, I'm surprised. I think it's more that if the lib is commonly included in most environments, like say readline is, then someone will have to download the lib seperately anyway, so you might as well have the soap functions be there at the same place. If your LGPL lib and / or an analog in BSD land are common, then including it in contrib would make perfect sense. ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib and licensing
On Wed, 2 Apr 2003, Marc G. Fournier wrote: On Wed, 2 Apr 2003, mlw wrote: Tom Lane wrote: mlw [EMAIL PROTECTED] writes: I know nothing in contrib should be GPL, I have no problem with that. The question is the requirement of a GPL library to build a contrib project. My SOAP/XML function will probably require my LGPL library as there is a lot of code I have written that I would need to implement it. If it won't work without your library then there's not much point in putting it into contrib. Might as well just put it in your library and distribute same as you have been doing. I'm a little put off by this attitude, are you saying there are no LGPL dependencies in PostgreSQL or /contrib? In fact, yes ... or, at least, if there are any left in /contrib, its only because we haven't moved them to gborg yet ... a program in /contrib linking to an LGPL lib has never been an issue. Linking to LGPL libs doesn't encumber the software linking to it. If that is a real objective, I'm surprised. The base source tree has always been as BSD pure as we can make it ... its never been kept a secret ... True. But not linking to LGPLd libs would be a bit extreme there. ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] contrib and licensing
mlw writes: I'm a little put off by this attitude, are you saying there are no LGPL dependencies in PostgreSQL or /contrib? No, the point is, why put it in contrib when someone who wants to use it has to download your library anyway. Then you might as well distribute the module next to that library. -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib and licensing
On Wed, 2 Apr 2003, scott.marlowe wrote: If that is a real objective, I'm surprised. The base source tree has always been as BSD pure as we can make it ... its never been kept a secret ... True. But not linking to LGPLd libs would be a bit extreme there. Correct, we've always had libreadline support, as a compile option, but libreadline is not part of the distribution, only the hooks to it are ... and, just recently, libedit(?) support was added as well, so that a non-GPL licensed alternative is available for those wishing to distribute the software ... ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] PostgreSQL and SOAP, suggestions?
mlw wrote: I think you are interpreting the spec a bit too restrictively. The syntax is fairly rigid, but the spec has a great degree of flexibility. I agree that, syntactically, it must work through a parser, but there is lots of room to be flexible. This is /exactly/ the standard problem with SOAP. There is enough flexibility that there are differing approaches associated, generally speaking, with IBM versus Microsoft whereby it's easy to generate SOAP requests that work fine with one that break with the other. For a pretty simple example of a longstanding bug that has never been fixed, see: http://sourceforge.net/tracker/index.php?func=detailaid=559324group_id=26590atid=387667 The precis: The SOAP implementation used by the XMethods folks to publish stock prices is buggy, rejecting perfectly legitimate messages submitted using ZSI (a Python SOAP implementation). The bug isn't with ZSI; it is quite clearly with the server, apparently implemented in Java using one of the EJB frameworks. In practice, what happens is that since that service is fairly popular, particularly for sample applications, the implementors of SOAP libraries wind up coding around the bugs. The problem is that it gets difficult to tell the difference between bugs and variations in interpretations of the standards. If the specs were more strictly defined, it would be a lot easier to use SOAP, because you wouldn't be left puzzling over whether the interoperability problems you're having are: a) Problems with the client; b) Problems with the server; c) Problems with interpretation of specs; d) ... The vast degree to which messages can get rewritten behind your back adds to the fun. Of course, it's only fun if you *enjoy* having interoperability problems... -- If this was helpful, http://svcs.affero.net/rm.php?r=cbbrowne rate me http://www.ntlug.org/~cbbrowne/soap.html He who laughs last thinks slowest. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] contrib and licensing
[snip] a program in /contrib linking to an LGPL lib has never been an issue. Linking to LGPL libs doesn't encumber the software linking to it. If that is a real objective, I'm surprised. The base source tree has always been as BSD pure as we can make it ... its never been kept a secret ... True. But not linking to LGPLd libs would be a bit extreme there. === NOTE UP FRONT -- Please email all flames directly to me at [EMAIL PROTECTED] ... === I disagree. Because of the language in the LGPL: http://www.gnu.org/copyleft/lesser.txt I would not use LGPL tools in any finished commercial project. For me, if PostgreSQL linked against LGPL libraries, it would kill its usefulness for me completely. One interpretation of the following: For example, if you distribute copies of the library, whether gratis or for a fee, you must give the recipients all the rights that we gave you. You must make sure that they, too, receive or can get the source code. If you link other code with the library, you must provide complete object files to the recipients, so that they can relink them with the library after making changes to the library and recompiling it. And you must show them these terms so they know their rights. Would be that tools that use LGPL libraries must also be distributed without cost. Consider this section: However, linking a work that uses the Library with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a work that uses the library. The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. LGPL is also a virus [IMO-YMMV]. Please send all flames directly to my email address [EMAIL PROTECTED] so we don't fill up the PG list with advocacy stuff. Commercial systems can get very paranoid over questionable legal language. Even if what it says is not what was intended -- that is still what it says and might possibly be enforced at some future time. Pure opinion of mine says... The BSD license is a very good license. The ACE license is a very good license. http://www.cs.wustl.edu/~schmidt/ACE-copying.html The MIT license is a very good license. There are others: http://www.opensource.org/licenses/ Now, I don't care if PostgreSQL has a TON of GPL stuff in it as long as it is OPTIONAL. I don't care if you have to use GPL/LGPL tools to build it, as long as they are not directly linked into it. ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] contrib and licensing
On Wed, 2003-04-02 at 18:00, Marc G. Fournier wrote: On Wed, 2 Apr 2003, scott.marlowe wrote: True. But not linking to LGPLd libs would be a bit extreme there. Correct, we've always had libreadline support, as a compile option Why is that relevant? libreadline is GPL'd, not LGPL'd. Cheers, Neil ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
[HACKERS] More protocol discussion: breaking down query processing
Last month's discussions about a revised FE/BE protocol make it clear that there is usefulness in breaking down the query-processing cycle and making individual steps available at the protocol level. This surfaced in several forms in the discussion, including requests for protocol-level PREPARE functionality, concerns about the inefficiency of fetching a RowDescription with each row pulled from a cursor, etc. Here are some thoughts about how to do this. There are two intermediate objects involved in processing a query: a parsed query and a cursor (perhaps we can find better names for them). The parsed query contains all the info needed to execute a query, except for actual values of any parameter placeholders used in the query. A cursor is a parsed query instantiated with actual parameter values; it's ready to execute and return rows (if the query returns any --- a cursor for an UPDATE, say, wouldn't return anything). Query processing can then be broken down into several steps. The PARSE step takes a query text string, and optionally some indication of the types of the parameters needed, and produces a parsed query object (this is exactly equivalent to the existing PREPARE command's functionality). Parameter types are induced from the query if not specified. The BIND step takes a parsed-query object and some actual parameter values and produces a ready-to-execute cursor. The FETCH step fetches some or all rows from a cursor. One may CLOSE a cursor when done with it, and may DEALLOCATE a parsed query object when it's no longer needed. We will also want a DESCRIBE operation that can be applied to either cursors or parsed queries (these perhaps should be thought of as two separate operations). Describing a cursor yields info about the output columns (equivalent to RowDescription message in the present protocol). Describing a parsed query yields RowDescription plus some description of the parameter(s). The existing Qsql statement command can now be thought of as a macro that invokes PARSE, BIND no parameters, DESCRIBE cursor, FETCH all from cursor, CLOSE, DEALLOCATE. We will still offer that all-in-one functionality, but we'll also offer an extended query command that allows any combination of these functions to be requested at the protocol level. These protocol operations are interoperable with the SQL-level commands for prepared queries and cursors, in the sense that a prepared query or open cursor can be created either way and then used either way. (Alternatively we might think that this is a bad idea, and that protocol-level operations should use a different namespace from SQL commands, so that application-requested operations can't interfere with state that the client-side library has set up. Any opinions?) The BIND operation will allow actual parameter values to be sent in either text or binary form; in either case we'll use a bytecount-followed-by-data format so that it's fully eight-bit-clean. I am inclined to think also that the FETCH operation should allow specification of whether it wants the results in text or binary form. It's not real clear how that should interoperate with the existing DECLARE BINARY CURSOR command, though --- which one should win if there's a conflict? All of these functions can specify the relevant parsed-query and cursor objects by name. A named parsed-query object lives until end of session unless deallocated. A named cursor object lives until end of transaction unless closed. (This might be extended to allow holdable cursors, though I'm more inclined to say that such things can only be created by SQL commands.) Alternatively, the protocol functions can reference nameless (zero-length-name) parsed-query and cursor objects. There can be only one of each of these, living only till the next one is created. The system can optimize nameless objects a little since it knows it need not save them beyond the end of the current query. The all-in-one query command always uses nameless objects. A difficulty with this scheme is that it doesn't scale very well to querystrings containing more than one SQL statement. For the all-in-one query command, we can just define that the BIND-DESCRIBE-FETCH-CLOSE cycle is automatically repeated for each parsetree constructed from the string; this is backwards-compatible with what happens now. It seems fairly messy to extend that to the case where the steps are individually commanded ... especially if you want to assume that the steps are being commanded by a client library that hasn't parsed the querystring and doesn't know how many commands exist therein. Perhaps we can get away with disallowing multiple commands per string when using the extended protocol. Comments? regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib and licensing
mlw [EMAIL PROTECTED] writes: Tom Lane wrote: If it won't work without your library then there's not much point in putting it into contrib. Might as well just put it in your library and distribute same as you have been doing. I'm a little put off by this attitude, are you saying there are no LGPL dependencies in PostgreSQL or /contrib? If that is a real objective, I'm surprised. The intention is that the entire distribution, including contrib, be under straight BSD license. This is a real objective --- we're not there yet, mainly because it's not being pursued vigorously with regard to the contrib modules already in place, but we think it is a valuable way of minimizing confusion. We have no problem at all with offering gborg project space to LGPL or GPL-licensed code; it's just that we don't want it in the core distribution, so that people don't have to hunt-and-peck through the distro to see which parts are under which license. Although you indicated willingness to provide the SOAP code per se as BSD license, it seems to me that this is rather pointless if it can't be used without an LGPL'd associated library. Someone who wanted a pure-BSD setup would still be unable to use the code. The SOAP code plus underlying library would be a more sensible distribution unit, and as such you might as well make it all LGPL. Of course, if you wanted to make it all BSD and put the whole mess in contrib, we'd be open to that idea ... regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] contrib and licensing
On Wednesday 02 April 2003 18:11, Dann Corbit wrote: [snip] True. But not linking to LGPLd libs would be a bit extreme there. I disagree. Because of the language in the LGPL: http://www.gnu.org/copyleft/lesser.txt I would not use LGPL tools in any finished commercial project. For me, if PostgreSQL linked against LGPL libraries, it would kill its usefulness for me completely. However, linking a work that uses the Library with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a work that uses the library. The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. stifles ROTFL Everyone does realize that on Linux PostgreSQL binaries link against glibc, which is LGPL.. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] contrib and licensing
On Wed, 2 Apr 2003, Lamar Owen wrote: On Wednesday 02 April 2003 18:11, Dann Corbit wrote: [snip] True. But not linking to LGPLd libs would be a bit extreme there. I disagree. Because of the language in the LGPL: http://www.gnu.org/copyleft/lesser.txt I would not use LGPL tools in any finished commercial project. For me, if PostgreSQL linked against LGPL libraries, it would kill its usefulness for me completely. However, linking a work that uses the Library with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a work that uses the library. The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. stifles ROTFL Everyone does realize that on Linux PostgreSQL binaries link against glibc, which is LGPL.. I assume the standard dynamic linker counts as a suitable shared library mechanism for linking with the Library as per LGPL 6b. ;) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Detecting corrupted pages earlier
On Wed, Apr 02, 2003 at 02:07:02PM -0700, Jason Earl wrote: There are some cases where this particular feature would be useful. What needs to be done is to make the feature less dangerous to the newbie without making it less useful to the person who actually needs the functionality. I'll repeat what I said before (I think to Tom): That's a pretty big foot-gun you've got there. I cannot possibly imagine what sort of data-recovery situation would warrant running with the option turned on all the time. You know you have big-trouble, oh-no, ISP ran over the tapes while they were busy pitching magnets through your cage, data corruption problems, and this is your best hope for recovery? Great. Log in, turn on this option, and start working. But across every back end? It's the doomsday device for databases. Emergency recovery options are _good_: everyone has his favourite UNIX file undeletion story. But it's sure not a good idea to give everyone root just in case she or he deletes some file. A -- Andrew Sullivan 204-4141 Yonge Street Liberty RMS Toronto, Ontario Canada [EMAIL PROTECTED] M2P 2A8 +1 416 646 3304 x110 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib and licensing
Lamar Owen [EMAIL PROTECTED] writes: stifles ROTFL Everyone does realize that on Linux PostgreSQL binaries link against glibc, which is LGPL.. And your point is? On other Unixoid systems you can link against BSD-license libc code, or some-random-proprietary-license code from HP or Sun or whomever. glibc doesn't have a monopoly in that sphere. But mlw is offering code that will *only* run against a single implementation that is LGPL licensed. That makes it effectively LGPL. regards, tom lane ---(end of broadcast)--- TIP 3: 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] Detecting corrupted pages earlier
Tom Lane wrote: Andrew Sullivan [EMAIL PROTECTED] writes: You know you have big-trouble, oh-no, ISP ran over the tapes while they were busy pitching magnets through your cage, data corruption problems, and this is your best hope for recovery? Great. Log in, turn on this option, and start working. But across every back end? It's the doomsday device for databases. Yeah, it is. Actually, the big problem with it in my mind is this scenario: you get a page-header-corrupted error on page X, you investigate and decide there's no hope for page X, so you turn on zero_damaged_pages and try to dump the table. It comes to page X, complains, zeroes it, proceeds, ... and then comes to damaged page Y, complains, zeroes it, proceeds. Maybe you didn't know page Y had problems. Maybe you could have gotten something useful out of page Y if you'd looked first. Too late now. What I'd really prefer to see is not a ZERO_DAMAGED_PAGES setting, but an explicit command to DESTROY PAGE n OF TABLE foo. That would make you manually admit defeat for each individual page before it'd drop data. But I don't presently have time to implement such a command (any volunteers out there?). Also, I could see where try-to-dump, fail, DESTROY, try again, lather, rinse, repeat, could get pretty tedious on a badly damaged table. Can we make the GUC setting a numeric, so you can set it to 1 and it clears just one page, or 0 and it clears all pages? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Detecting corrupted pages earlier
What I'd really prefer to see is not a ZERO_DAMAGED_PAGES setting, but an explicit command to DESTROY PAGE n OF TABLE foo. That would make you manually admit defeat for each individual page before it'd drop data. But I don't presently have time to implement such a command (any volunteers out there?). Also, I could see where try-to-dump, fail, DESTROY, try again, lather, rinse, repeat, could get pretty tedious on a badly damaged table. I'm not volunteering, but this would be better: ALTER TABLE foo ZERO [ PAGE n | BAD PAGES ]; Chris ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Detecting corrupted pages earlier
On Wed, Apr 02, 2003 at 11:10:13PM -0500, Tom Lane wrote: What I'd really prefer to see is not a ZERO_DAMAGED_PAGES setting, but an explicit command to DESTROY PAGE n OF TABLE foo. That would make you manually admit defeat for each individual page before it'd drop data. But I don't presently have time to implement such a command (any volunteers out there?). Also, I could see where try-to-dump, fail, DESTROY, try again, lather, rinse, repeat, could get pretty tedious on a badly damaged table. Huh, and what if I accidentaly mistype the number and destroy a valid page? Maybe the command should only succeed if it confirms that the page is corrupted. There could also be DESTROY ALL PAGES and/or DESTROY n PAGES commands, where the latter zeroes the first n corrupted pages in the table, for the case with lots of corrupted pages. Maybe a command for getting a list of the corrupted pages is useful? -- Alvaro Herrera (alvherre[a]dcc.uchile.cl) La verdad no siempre es bonita, pero el hambre de ella si ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Detecting corrupted pages earlier
Andrew Sullivan [EMAIL PROTECTED] writes: You know you have big-trouble, oh-no, ISP ran over the tapes while they were busy pitching magnets through your cage, data corruption problems, and this is your best hope for recovery? Great. Log in, turn on this option, and start working. But across every back end? It's the doomsday device for databases. Yeah, it is. Actually, the big problem with it in my mind is this scenario: you get a page-header-corrupted error on page X, you investigate and decide there's no hope for page X, so you turn on zero_damaged_pages and try to dump the table. It comes to page X, complains, zeroes it, proceeds, ... and then comes to damaged page Y, complains, zeroes it, proceeds. Maybe you didn't know page Y had problems. Maybe you could have gotten something useful out of page Y if you'd looked first. Too late now. What I'd really prefer to see is not a ZERO_DAMAGED_PAGES setting, but an explicit command to DESTROY PAGE n OF TABLE foo. That would make you manually admit defeat for each individual page before it'd drop data. But I don't presently have time to implement such a command (any volunteers out there?). Also, I could see where try-to-dump, fail, DESTROY, try again, lather, rinse, repeat, could get pretty tedious on a badly damaged table. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Detecting corrupted pages earlier
Alvaro Herrera [EMAIL PROTECTED] writes: Huh, and what if I accidentaly mistype the number and destroy a valid page? Maybe the command should only succeed if it confirms that the page is corrupted. Good point ... but what if the corruption is subtle enough that the automatic tests don't notice it? It could be that only SELECT * FROM ... actually dumps core. This is an acute problem for tests that are generic enough to be implemented in just one or a few places --- for example, the tests I just added have no idea whether they are looking at a heap or index page, much less what kind of index page. There could also be DESTROY ALL PAGES and/or DESTROY n PAGES commands, where the latter zeroes the first n corrupted pages in the table, for the case with lots of corrupted pages. Maybe a command for getting a list of the corrupted pages is useful? We have DESTROY ALL PAGES, it's called DROP TABLE. The other doesn't appeal to me either, because it doesn't say exactly which N pages you're willing to lose. regards, tom lane ---(end of broadcast)--- TIP 3: 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] contrib and licensing
On Wednesday 02 April 2003 22:39, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: stifles ROTFL Everyone does realize that on Linux PostgreSQL binaries link against glibc, which is LGPL.. And your point is? That everyone is being entirely too picky. Hey, we link against other things, too. Some aren't LGPL. The readline example is a good one, incidentally: it's GPL. And its stubs are in the backend, of all places. At least on Linux. Gotta watch any 'static builds' then. On other Unixoid systems you can link against BSD-license libc code, or some-random-proprietary-license code from HP or Sun or whomever. glibc doesn't have a monopoly in that sphere. But mlw is offering code that will *only* run against a single implementation that is LGPL licensed. That makes it effectively LGPL. One could clean-room reimplement if the demand is enough. But, if one wants to get picky, let's talk about the license issue of PL/Python. The PSF looks like a rat's nest. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] contrib and licensing
Lamar Owen [EMAIL PROTECTED] writes: And your point is? That everyone is being entirely too picky. Hey, we link against other things, too. Some aren't LGPL. The readline example is a good one, incidentally: it's GPL. Yeah, it's an excellent example: there is an alternative implementation under a different license (libedit). And its stubs are in the backend, of all places. Really? I must have missed that. One could clean-room reimplement if the demand is enough. Certainly, any of this stuff *could* be reimplemented. But for stuff that's being proposed for contrib, what's theoretically possible given enough demand isn't the important real-world issue. Contrib stuff is, by definition, stuff that hasn't yet had all that much work put into it. So it's appropriate to ask where it can really run *right now*. regards, tom lane ---(end of broadcast)--- TIP 3: 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] contrib and licensing
On Wednesday 02 April 2003 21:59, Stephan Szabo wrote: On Wed, 2 Apr 2003, Lamar Owen wrote: However, linking a work that uses the Library with the Library creates an executable that is a derivative of the Library (because it contains portions of the Library), rather than a work that uses the library. The executable is therefore covered by this License. Section 6 states terms for distribution of such executables. Everyone does realize that on Linux PostgreSQL binaries link against glibc, which is LGPL.. I assume the standard dynamic linker counts as a suitable shared library mechanism for linking with the Library as per LGPL 6b. ;) Then I guess we had better not make any static linked builds, no? The whole thread just got ridiculous, that's all. So I attempted to illuminate the 'ridiculosity' of the whole matter. Speaking of 'ridiculous' reminds me: Readline is full-bore GPL. There's no 6b exception there. We dynamically link readline, on most Linux distributions. Of course, Tom has a point; there are alternatives available. None are as good as readline, though. Which is one of the reasons it's GPL'd in the first place, according the the GPL FAQ. In fact, the GPL FAQ contains this little tidbit: 'If a library is released under the GPL (not the LGPL), does that mean that any program which uses it has to be under the GPL? Yes, because the program as it is actually run includes the library.' :-O Hmmm. 'as it is actually run' means with the library embedded in the resulting dynamically linked program -- just because it's dynamically linked doesn't mean that code isn't part of the program. Should we say 'bye bye' to readline? Of course, there's the issue of the BSD license being 'compatible' with the GPL. Then it gets hairy. And picky. Fun fun fun. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] contrib and licensing
On Thursday 03 April 2003 00:04, Tom Lane wrote: Lamar Owen [EMAIL PROTECTED] writes: And its stubs are in the backend, of all places. Really? I must have missed that. On Linux as compiled in Red Hat 9, at least: [EMAIL PROTECTED] lowen]$ ldd /usr/bin/postgres libpam.so.0 = /lib/libpam.so.0 (0x4002c000) libssl.so.4 = /lib/libssl.so.4 (0x40034000) libcrypto.so.4 = /lib/libcrypto.so.4 (0x40069000) libkrb5.so.3 = /usr/kerberos/lib/libkrb5.so.3 (0x4015a000) libz.so.1 = /usr/lib/libz.so.1 (0x401b8000) libreadline.so.4 = /usr/lib/libreadline.so.4 (0x401c6000) libtermcap.so.2 = /lib/libtermcap.so.2 (0x401f3000) libcrypt.so.1 = /lib/libcrypt.so.1 (0x401f7000) libresolv.so.2 = /lib/libresolv.so.2 (0x40224000) libnsl.so.1 = /lib/libnsl.so.1 (0x40236000) libdl.so.2 = /lib/libdl.so.2 (0x4024b000) libm.so.6 = /lib/tls/libm.so.6 (0x4024e000) libc.so.6 = /lib/tls/libc.so.6 (0x4200) libcom_err.so.3 = /usr/kerberos/lib/libcom_err.so.3 (0x40271000) libgssapi_krb5.so.2 = /usr/kerberos/lib/libgssapi_krb5.so.2 (0x40273000) libk5crypto.so.3 = /usr/kerberos/lib/libk5crypto.so.3 (0x40286000) /lib/ld-linux.so.2 = /lib/ld-linux.so.2 (0x4000) [EMAIL PROTECTED] lowen]$ /usr/bin/postgres --version postgres (PostgreSQL) 7.3.2 [EMAIL PROTECTED] lowen]$ Certainly, any of this stuff *could* be reimplemented. But for stuff that's being proposed for contrib, what's theoretically possible given enough demand isn't the important real-world issue. Contrib stuff is, by definition, stuff that hasn't yet had all that much work put into it. So it's appropriate to ask where it can really run *right now*. FWIW, very few things in contrib use anything beyond libc. The dblink stuff is a notable exception. It needs an SSL and a Kerberos 5 library. If the library is reasonably popular (meaning it's in at least one major OS distribution, including Debian) then 'what's the harm?' If the lib isn't that popular, then, regardless of license the question 'should something that uses it even be here' should be asked. The issue of a straight GPL library is serious for us; a LGPL one less so. -- Lamar Owen WGCR Internet Radio 1 Peter 4:11 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] 7.4devel auth failed
Looks like Tom just checked a fix into CVS for your reported problem.
Would you please test it?
---
Andreas Pflug wrote:
Ok Bruce,
I found out what's happening.
I'm running a Suse 8.1 2.4.19 standard kernel which has IPV6 enabled by
default. When connecting locally over IP (pgaccess), hba is checked
against IPV6 patterns in pg_hba.conf.
My pgadmin2 machine will connect with an IP4-to-6 mapped address of
0::c0a80002 (192.168.0.2), which convSockAddr6to4 will convert to
dst-in.sin_addr.s_addr=0xc0a80002. On the other side, SockAddr_pton
will convert my 192.168.0.0/255.255.255.0 entry to a8c0/ff, and
consequently rangeSockAddr will fail.
If your kernel isn't V6 enabled, the incoming socket will be AF_INET,
and no conversion is done, that's why you don't get the problem.
To fix this, the [12]..[15] indices need to be reversed (for Intel).
This might be machine specific... Maybe for all big-endian machines the
current code is ok, and needs reversal for little-endian processors.
I wonder if the following is completely portable, could be:
dst-in.sin_addr.s_addr = *(in_addr_t*)(src-in4.sin6_addr.s6_addr+12);
Regards,
Andreas
PS Your mail host candle.pha.pa.us rejected this mail as spam?!?
Bruce Momjian wrote:
That's strange. I just tested it here, and it worked. I have IPv6 code
enabled. but no IPv6 in my kernel, so there are just IPv4 connections.
Can you peek in this funciton and see where it is failing:
int
rangeSockAddrAF_INET(const SockAddr *addr, const SockAddr *netaddr,
const SockAddr *netmask)
{
if (addr-sa.sa_family != AF_INET ||
netaddr-sa.sa_family != AF_INET ||
netmask-sa.sa_family != AF_INET)
return 0;
if (((addr-in.sin_addr.s_addr ^ netaddr-in.sin_addr.s_addr)
netmask-in.sin_addr.s_addr) == 0)
return 1;
else
return 0;
}
That is the IPv4 function.
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send unregister YourEmailAddressHere to [EMAIL PROTECTED])
--
Bruce Momjian| http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup.| Newtown Square, Pennsylvania 19073
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] TODO list problem or am I way off base?
OK, I have removed the TODO item. Thanks. --- Frank Wiles wrote: Hey Guys, Sorry if this should go to another list, but I was looking over the TODO list for something small I could cut my teeth on and noticed you have the following listed in the TODO in the 'Source Code' section: * Add --port flag to regression tests And based on what I can tell the shell script src/test/regress/pg_regress.sh already has the ability to define the port with --port. It sets the PGPORT environment variable. - Frank Wiles [EMAIL PROTECTED] http://frank.wiles.org - ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Dangling backends on win32 7.2.1 port (peerdirect).
Jan Wieck wrote: Merlin Moncure wrote: TRY TEST WIN32 PORT. DATABASE GO BOOM! TRY FIX NOBODY CARE. WIN32 PORT COME OUT MANY DATABASE GO BOOM! TRY HELP GET IGNORED. JUST WANT HELP. BUG FIX? Pardonne moi? What exactly did you test? If it is the PeerDirect Beta version of PostgreSQL for Windows named UltraSQL, please know that thus far there has to my knowledge not been an offical, supported release of UltraSQL yet - and since the company eliminated the group working on that port, I doubt there ever will. PeerDirect tried to contribute the Win32 port portion of their work to the open source project. The PostgreSQL global development team has not yet made any final decision if or what parts of that code will or will not become part of the regular PostgreSQL distribution. Actually, I believe we have decided to use the PeerDirect code to do a native Win32 port for 7.4. I just posted my first patch, and will spend most of the next two months completing the job. -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
