Re: [HACKERS] ARC patent
I think the ARC issue is the same with any other patent ... Recently somebody pointed me to a nice site showing some examples: http://www.base.com/software-patents/examples.html Looking at the list briefly I can find at least five patent problems using any operating system with PostgreSQL. From my point of view having the ARC in there is just as safe / unsafe as using Hello World and compile it with GCC. I don't think it possible to sue a community anyway. Best regards and have fun reading those examples, Hans -- Cybertec Geschwinde u Schoenig Schoengrabern 134, A-2020 Hollabrunn, Austria Tel: +43/660/816 40 77 www.cybertec.at, www.postgresql.at ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] psql 8.0 final not working on NT 4.0sp6
I'm running 'psql.exe -- version' and I'm getting this dialog: psql.exe - Entry Point Not Found: The procedure entry point SHGetSpecialFolderPathA could not be located in the dynamic link library SHELL32.DLL. I got this for both the version I compiled and psql from the pgInstaller (both operations done on Windows XP). I suppose that the compiler and/or installer could be doing something different for Windows NT? The last version I tested on NT 4 was 8.0.0rc-1 which works OK. I'm also curious as to why the version of psql I compile is about 7K bytes smaller than what the installer gives me. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(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] US Patents vs Non-US software ...
On Tue, Jan 18, 2005 at 09:22:58AM +0200, Nicolai Tufar wrote: Greetings, Patents do not transcend international border. They need to be applied for in each country separately. To ease the process of applying for patents in many countries at once Patent Cooperation Treaty (PCT) was formed. When you It's also true that many countried have bilateral treatings respecting the intellectual property in the other country. Canada has such with the US, as far as I know, so that it is possible to request injunctive relief in Canada for violation of a patent which is grated by the USPTO. The relief is limited, however, and requires certain hoop-jumping which is sort of tiresome. Unless, of course, you have a large, full time legal staff and you're already a multinational. A -- Andrew Sullivan | [EMAIL PROTECTED] The plural of anecdote is not data. --Roger Brinner ---(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] Is CVS HEAD open for 8.1 commits?
On Tue, 18 Jan 2005, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Tom Lane wrote: I'm not convinced Marc got the branching/tagging right; let's wait till the dust settles. I IM'ed him and he said to go ahead. Maybe he said that, but I see no evidence that he's tagged 8.0.0 correctly. If you touch the repository you'll make it materially harder to fix this. So HOLD OFF, please. Too late, sorry. Marc says the 8.0.0 is a tag and a branch. Note that REL8_0_STABLE is the tag/branch ... HEAD should be clear to commit to ... the error that Tom was eluding to was that I had mis-named the original branch as REL8_0_0, instead of REL8_0_STABLE ... if someone knows how to safely remove a branch that has had no commits made to it, please let me know, but from reading the docs, the suggestions that seemed to be suggested had very big *BEWARE* signs around them ... tags are easy to move around and remove, branches, apparently, aren't so simple ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Is CVS HEAD open for 8.1 commits?
Marc G. Fournier wrote: On Tue, 18 Jan 2005, Bruce Momjian wrote: Tom Lane wrote: Bruce Momjian pgman@candle.pha.pa.us writes: Tom Lane wrote: I'm not convinced Marc got the branching/tagging right; let's wait till the dust settles. I IM'ed him and he said to go ahead. Maybe he said that, but I see no evidence that he's tagged 8.0.0 correctly. If you touch the repository you'll make it materially harder to fix this. So HOLD OFF, please. Too late, sorry. Marc says the 8.0.0 is a tag and a branch. Note that REL8_0_STABLE is the tag/branch ... HEAD should be clear to commit to ... the error that Tom was eluding to was that I had mis-named the original branch as REL8_0_0, instead of REL8_0_STABLE ... if someone knows how to safely remove a branch that has had no commits made to it, please let me know, but from reading the docs, the suggestions that seemed to be suggested had very big *BEWARE* signs around them ... tags are easy to move around and remove, branches, apparently, aren't so simple ... Quite so. Only by direct hacking on the ,v files, AFAIK - i.e. NOT something to be done except in dire emergency. As long as nobody commits to the branch is there any harm done by leaving it there? I presume all the committers know which branch they should be committing to (and also that most other than Tom only rarely commit to anything other than HEAD) cheers andrew ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] psql 8.0 final not working on NT 4.0sp6
On Jan 18, 2005, at 11:05 AM, Magnus Hagander wrote: Hmm. That would seem to have it. Can you check the version on your SHELL32.DLL? The MSDN docs for the version in question (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ shellc c/platform/shell/reference/functions/shgetspecialfolderpath.asp) claims it needs either Win2k or The IE 4.0 Desktop Update. Which resolves to shell32.dll version 4.71 or later. WINNT\System32\Shell32.dll is version 4.00, so that appears to be the problem. According to this: http://support.microsoft.com/kb/q165695/ Windows Desktop update was included with IE 4, but not with IE 5 or later. Further, if you want to install Windows Desktop Update you have to first remove IE 5 or later. And finally it says that Windows Desktop Update can only be installed using the IE 4 setup, but this is no longer available from Microsoft. What a mess. hackers-win32 is prboably slightly more on-topic OK, will do for next time. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] psql 8.0 final not working on NT 4.0sp6
Hi Magnus, On Jan 18, 2005, at 10:50 AM, Magnus Hagander wrote: I'm running 'psql.exe -- version' and I'm getting this dialog: psql.exe - Entry Point Not Found: The procedure entry point SHGetSpecialFolderPathA could not be located in the dynamic link library SHELL32.DLL. Do you have the IE4 Desktop Update installed? I think so. System Properties for my computer shows NT 4.00.1381 IE 5 5.50.4308.2900 If this is not what you are asking, let me know where to look. I'm also curious as to why the version of psql I compile is about 7K bytes smaller than what the installer gives me. SSL suport possibly? Use pg_config from the installer to find the exact commandline used for that. If that's not it, then different version of mingw gcc probably. That's it -- thanks. If I'm posting to the wrong list for this, please let me know. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] psql 8.0 final not working on NT 4.0sp6
I'm running 'psql.exe -- version' and I'm getting this dialog: psql.exe - Entry Point Not Found: The procedure entry point SHGetSpecialFolderPathA could not be located in the dynamic link library SHELL32.DLL. Do you have the IE4 Desktop Update installed? I think so. System Properties for my computer shows NT 4.00.1381 IE 5 5.50.4308.2900 If this is not what you are asking, let me know where to look. Hmm. That would seem to have it. Can you check the version on your SHELL32.DLL? The MSDN docs for the version in question (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/shellc c/platform/shell/reference/functions/shgetspecialfolderpath.asp) claims it needs either Win2k or The IE 4.0 Desktop Update. Which resolves to shell32.dll version 4.71 or later. I'm also curious as to why the version of psql I compile is about 7K bytes smaller than what the installer gives me. SSL suport possibly? Use pg_config from the installer to find the exact commandline used for that. If that's not it, then different version of mingw gcc probably. That's it -- thanks. If I'm posting to the wrong list for this, please let me know. hackers-win32 is prboably slightly more on-topic. //Magnus ---(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] Is CVS HEAD open for 8.1 commits?
On Tue, 18 Jan 2005, Andrew Dunstan wrote: Quite so. Only by direct hacking on the ,v files, AFAIK - i.e. NOT something to be done except in dire emergency. As long as nobody commits to the branch is there any harm done by leaving it there? I presume all the committers know which branch they should be committing to (and also that most other than Tom only rarely commit to anything other than HEAD) This is what we figured, I just wanted to make sure that I wasn't overlooking something ... risk is minimal, but eliminating it would have been nice if possible :) Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql 8.0 final not working on NT 4.0sp6
Hmm. That would seem to have it. Can you check the version on your SHELL32.DLL? The MSDN docs for the version in question (http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ shellc c/platform/shell/reference/functions/shgetspecialfolderpath.asp) claims it needs either Win2k or The IE 4.0 Desktop Update. Which resolves to shell32.dll version 4.71 or later. WINNT\System32\Shell32.dll is version 4.00, so that appears to be the problem. According to this: http://support.microsoft.com/kb/q165695/ Windows Desktop update was included with IE 4, but not with IE 5 or later. Further, if you want to install Windows Desktop Update you have to first remove IE 5 or later. And finally it says that Windows Desktop Update can only be installed using the IE 4 setup, but this is no longer available from Microsoft. What a mess. Yikes. that's certainly a mess. I see the following options: 1) Declare NT4 without IE4 unsupported. This is by far the easiest :P What we'd do later is add a check to the MSI installer to inform the user about this. 2) Revert to the pre-8.0 behaviour with the files. This is IMHO a very bad idea, because that was not well-behaved on *current* Windows platforms. 3) Change to using SHGetFolderPath() linked from shfolder.dll (note that this function exists in two different dlls. We'd need the one in shfolder.dll to have any effect). And then point people who don't have shfolder.dll to the Microsoft download site for this file (it's redistributable, but only in an unmodified self-extracting file, so we can't easily embed it in the installer. can be done, but not as easy as one would like). It will be required on most systems running 95, 98 and NT4 (without it we'll be broken on 95 and 98, which work today). The file is included on current windows versions by default. This is probably the nicest idea, but I'm not sure how much work we want to throw into the NT4 support. Considering MS has stopped supporting it even to their pay-through-the-nose-for-support customers by now. (and we *do* work on NT4 as long as the user has installed IE4) Thoughts? //Magnus ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] ARC patent
Andrew Dunstan [EMAIL PROTECTED] writes: Simon Riggs wrote: So, it also seems clear that 8.0.x should eventually have a straight upgrade path to a replacement, assuming the patent is granted. We should therefore plan to: 1. improve/replace ARC for 8.1 2. backport any replacement directly onto 8.0STABLE as soon as any patent is granted One of the reasons for Postgres' well deserved reputation for stability and reliability is that stable branches are ... stable. Backporting a large item like cache replacement mechanism doesn't seem to fit that too well. I wouldn't want to do that except as a complete last resort. Exactly, which is why it probably won't happen. Tom's got the right idea. Simply release 8.0, and then start planning for 8.1. If and when IBM gets this patent approved, and if and when IBM starts sending out letters then PostgreSQL will be prepared with non-infringing versions. The *real* moral of the story, however, is that it is not smart for developers to go poking through patent databases. The real problems with patents begin when the patent holder can prove that you *knew* about an *approved* patent and still released the software anyhow. So don't browse through the patent databases, and for heaven's sake, if you find a patent that PostgreSQL *might* be infringing whatever you do don't post about it on the PostgreSQL mailing lists. I am not a lawyer, but I think that the only sane thing to do is to follow the lead of the Linux kernel developers and stay away from any sort of patent research. You really don't want to know how many patents PostgreSQL is infringing, and you certainly don't want to talk about it on a public forum (or anywhere else). My guess is that IBM isn't likely to be interested in spending millions of dollars litigating agains the PostgreSQL project and various PostgreSQL end users. Suing customers (and potential customers) is always bad form, and chasing after a Free Software project is likely to be a PR disaster. However, even if IBM were interested in cashing in on this patent, they can't do that until the patent is actually granted. Jason ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql 8.0 final not working on NT 4.0sp6
Hi Magnus, On Jan 18, 2005, at 1:34 PM, Magnus Hagander wrote: 1) Declare NT4 without IE4 unsupported. This is by far the easiest :P What we'd do later is add a check to the MSI installer to inform the user about this. Seems a bit gross to say that NT4 is supported, but only if you happen to have a really old version of IE (or you happened to install it and choose the right option somewhere along your way to a later IE version). If I read the MS page correctly, having IE 4 installed does not guarantee things will work. You must have chosen the option to install Windows Desktop Update. I would not be surprised if I did this -- I hate the Windows explorer interfaces that tries to make everything look like a web page :). 2) Revert to the pre-8.0 behaviour with the files. This is IMHO a very bad idea, because that was not well-behaved on *current* Windows platforms. Is it not possible to add a version check and just use the old method with Windows NT? What is this function call used to get other than the user's home directory? 3) Change to using SHGetFolderPath() linked from shfolder.dll (note that this function exists in two different dlls. We'd need the one in shfolder.dll to have any effect). And then point people who don't have shfolder.dll to the Microsoft download site for this file (it's redistributable, but only in an unmodified self-extracting file, so we can't easily embed it in the installer. can be done, but not as easy as one would like). It will be required on most systems running 95, 98 and NT4 (without it we'll be broken on 95 and 98, which work today). The file is included on current windows versions by default. This is probably the nicest idea, but I'm not sure how much work we want to throw into the NT4 support. Considering MS has stopped supporting it even to their pay-through-the-nose-for-support customers by now. (and we *do* work on NT4 as long as the user has installed IE4) I certainly understand not wanting to spend a bunch of time on NT support. But everything seemed fine through 8.0.0-rc1, so I would hate to see it go away over this one issue. I did not realize that 95/98 worked at all. I don't think anyone really wants to setup a server on 95, 98, or even NT4, but it would be really nice if psql would work. John DeSoi, Ph.D. http://pgedit.com/ Power Tools for PostgreSQL ---(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
[HACKERS] Some things I like to pick from the TODO list ...
Hi *, I have some cylcles left and like to pick up something from the TODO list. These are the things I'm interested in: 1) Allow limits on per-db/user connections 2) Allow server log information to be output as INSERT statements 3) Allow GRANT/REVOKE permissions to be applied to all schema objects with one 4) Allow PREPARE of cursors what's free, what's apropriate for a newbee like me? cheers, Matthias -- Matthias Schmidt Viehtriftstr. 49 67346 Speyer GERMANY Tel.: +49 6232 4867 Fax.: +49 6232 640089 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Some things I like to pick from the TODO list ...
On Tue, Jan 18, 2005 at 08:15:10PM +0100, Matthias Schmidt wrote: 1) Allow limits on per-db/user connections Sounds hard to do: what limits? CPU, disk? 2) Allow server log information to be output as INSERT statements Is this really needed? 3) Allow GRANT/REVOKE permissions to be applied to all schema objects with one Maybe this is apply schema changes to several objects with one command. This seems reasonable. 4) Allow PREPARE of cursors What does this means? Do you use an EXECUTE FETCH afterwards? Doesn't make a lot of sense to me. -- Alvaro Herrera ([EMAIL PROTECTED]) Porque francamente, si para saber manejarse a uno mismo hubiera que rendir examen... ¿Quién es el machito que tendría carnet? (Mafalda) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] US Patents vs Non-US software ...
On Tue, 18 Jan 2005 09:22:58 +0200 Many countries do not grant software patents so it is not likely that IBM applied through PCT since a refusal in one country may cause to patent to be refused in all countries. Contrary to popular misconception, virtually all countries grant software patents. The problem is that people have applied the term software patent to USPTO-specific lameness like one-click shopping, which really is outside the scope of traditional software patents. While most countries do not grant patents for this flavor of frivolousness, they do grant hard-theory algorithm design patents across virtually all types of machinery (including virtual machinery). Traditional software design patents are structurally and functionally indistinguishable from chemical process patents, which are generally recognized as valid in most countries. Software patents have to have novelty that survives reduction to general process design (and the ARC algorithm looks like it qualifies) if you want most countries to grant it. The problem with USPTO and so-called software patents is that they allow people to patent what is essentially prior art with re-named variables. Chemical process patents are a good analogy because literally every argument used against software patents could be used against chemical process patents, which no one apparently finds controversial. What often passes for material novel-ness in software processes with the USPTO would never fly for chemical processes with the same USPTO. If someone invents a better pipe alloy for carrying chemical fluids, you cannot re-patent all chemical processes with the novelty being that you use a better type of pipe -- that change is not material to the chemical process, even if it improves the economics of it in some fashion. The only thing patentable would be the superior alloy design in the abstract. Most of the lame software patents are lame because reduction to machine process design gives you something that is decidedly non-novel. In other words, the novel-ness is the semantic dressing-up of a non-novel engineering process. cheers, j. andrew rogers ---(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] Some things I like to pick from the TODO list ...
Matthias Schmidt [EMAIL PROTECTED] writes: These are the things I'm interested in: 1) Allow limits on per-db/user connections 2) Allow server log information to be output as INSERT statements 3) Allow GRANT/REVOKE permissions to be applied to all schema objects with one 4) Allow PREPARE of cursors what's free, what's apropriate for a newbee like me? I'd vote for #3 just because it'd be much the most useful --- we get requests for that every other day, it seems like. The others are far down the wish-list. It's also localized enough that I think a newbie could handle it. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Some things I like to pick from the TODO list ...
* Matthias Schmidt ([EMAIL PROTECTED]) wrote: 3) Allow GRANT/REVOKE permissions to be applied to all schema objects with one This would be nice. I had to write a perl script to do it here. :) It'd also be nice to be able to specify a set of permissions that will be inheirited by newly created objects in a schema. Something like: grant select,insert,update on schema DEFAULT to group xyz; Stephen signature.asc Description: Digital signature
Re: [HACKERS] Much Ado About COUNT(*)
Jonah == Jonah H Harris [EMAIL PROTECTED] writes: Jonah Replying to the list as a whole: Jonah If this is such a bad idea, why do other database systems Jonah use it? As a businessperson myself, it doesn't seem Jonah logical to me that commercial database companies would Jonah spend money on implementing this feature if it wouldn't be Jonah used. Remember guys, I'm just trying to help. Systems like DB2 don't implement versioning schemes. As a result there is no need to worry about maintaining visibility in indexes. Index-only plans are thus viable as they require no change in the physical structure of the index and no overhead on update/delete/insert ops. I don't know about Oracle, which I gather is the only commercial system to have something like MVCC. -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Much Ado About COUNT(*)
On Tue, 2005-01-18 at 12:45 -0800, Sailesh Krishnamurthy wrote: Jonah == Jonah H Harris [EMAIL PROTECTED] writes: Jonah Replying to the list as a whole: Jonah If this is such a bad idea, why do other database systems Jonah use it? As a businessperson myself, it doesn't seem Jonah logical to me that commercial database companies would Jonah spend money on implementing this feature if it wouldn't be Jonah used. Remember guys, I'm just trying to help. Systems like DB2 don't implement versioning schemes. As a result there is no need to worry about maintaining visibility in indexes. Index-only plans are thus viable as they require no change in the physical structure of the index and no overhead on update/delete/insert ops. I don't know about Oracle, which I gather is the only commercial system to have something like MVCC. Perhaps firebird/interbase also? Someone mentioned that on these lists, I'm not sure if it's true or not. I almost think to not supply an MVCC system would break the I in ACID, would it not? I can't think of any other obvious way to isolate the transactions, but on the other hand, wouldn't DB2 want to be ACID compliant? Regards, Jeff Davis ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Is CVS HEAD open for 8.1 commits?
On Tue, 18 Jan 2005 at 11:53, Marc G. Fournier wrote: ... if someone knows how to safely remove a branch that has had no commits made to it, please let me know, a little bit of googling brought me to this: http://lists.gnu.org/archive/html/info-cvs/2003-11/msg00166.html --- snip --- How can the name of a tag that is a branch point be changed [...] cvs admin -n newname:oldname cvs tag -Bd oldname --- snap --- cu Reinhard ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Some things I like to pick from the TODO list ...
Alvaro Herrera schrieb: On Tue, Jan 18, 2005 at 08:15:10PM +0100, Matthias Schmidt wrote: 1) Allow limits on per-db/user connections Sounds hard to do: what limits? CPU, disk? Note that a typical server limit, the load average, will not be portable. There's no WIN32 solution yet. The CPU load is also not really easy to port, but there exist solutions. But I guess you are only talking about restricting client connections, which is easy enough. -- Reini Urban ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] ARC patent
On Mon, 2005-01-17 at 15:11 -0500, Andrew Dunstan wrote: There's a very recent paper at http://carmen.cs.uiuc.edu/~zchen9/paper/TPDS-final.ps on an alternative to ARC which claims superior performance ... From a quick glance, this doesn't look applicable. The authors are discussing buffer replacement strategies for a multi-level cache hierarchy (e.g. they would call the DBMS buffer cache L1, and the kernel I/O cache L2 -- note that despite the terminology, this has little in common with L1/L2 caches in processors). They don't really address caching for the L1-only case -- they're concerned with proposing algorithms to manage the L2 cache (with or without explicit knowledge about the content of the L1 cache). A few years ago Tom implemented the LRU-K replacement policy[1], but AFAIK the performance results from that weren't very positive (since the implementation of LRU-K requires a heap and is therefore logarithmic rather than constant time, that makes sense). The 2Q algorithm looks like it might be worth investigating[2]. -Neil [1] http://citeseer.ist.psu.edu/16869.html [2] http://citeseer.ist.psu.edu/63909.html ---(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] Much Ado About COUNT(*)
Jeff Davis [EMAIL PROTECTED] writes: I almost think to not supply an MVCC system would break the I in ACID, would it not? Certainly not; ACID was a recognized goal long before anyone thought of MVCC. You do need much more locking to make it work without MVCC, though --- for instance, a reader that is interested in a just-modified row has to block until the writer completes or rolls back. People who hang around Postgres too long tend to think that MVCC is the obviously correct way to do things, but much of the rest of the world thinks differently ;-) regards, tom lane ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Much Ado About COUNT(*)
Tom == Tom Lane [EMAIL PROTECTED] writes: Tom People who hang around Postgres too long tend to think that Tom MVCC is the obviously correct way to do things, but much of Tom the rest of the world thinks differently ;-) It works the other way too ... people who come from the locking world find it difficult to wrap their heads around MVCC. A big part of this is because Gray's original paper on transaction isolation defines the different levels based on what kind of lock acquisitions they involve. A very nice alternative approach to defining transaction isolation is Generalized isolation level definitions by Adya, Liskov and O'Neill that appears in ICDE 2000. -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] Much Ado About COUNT(*)
Certainly not; ACID was a recognized goal long before anyone thought of MVCC. You do need much more locking to make it work without MVCC, though --- for instance, a reader that is interested in a just-modified row has to block until the writer completes or rolls back. People who hang around Postgres too long tend to think that MVCC is the obviously correct way to do things, but much of the rest of the world thinks differently ;-) Well, that would explain why everyone is so happy with PostgreSQL's concurrent access performance. Thanks for the information, although I'm not sure I wanted to be reminded about complicated locking issues ( I suppose I must have known that at one time, but perhaps I surpressed it ;-) Regards, Jeff Davis ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] ARC patent
On Mon, 2005-01-17 at 18:43 -0500, Tom Lane wrote: I have already suggested to core that we should insist on 8.1 not requiring an initdb, so as to ensure that people will migrate up to it easily from 8.0. So is it firm policy that changes that require a catversion update cannot be made during the 8.1 cycle? (Needless to say, it would be good to get this sorted out early on in the 8.1 development cycle, to avoid the need to revert patches at some point down the line. For those of us working on large projects that will definitely require an initdb, it would also be good to know -- as this policy will likely prevent that work from getting into 8.1) -Neil ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] ARC patent
On Wed, Jan 19, 2005 at 10:48:00AM +1100, Neil Conway wrote: On Mon, 2005-01-17 at 18:43 -0500, Tom Lane wrote: I have already suggested to core that we should insist on 8.1 not requiring an initdb, so as to ensure that people will migrate up to it easily from 8.0. So is it firm policy that changes that require a catversion update cannot be made during the 8.1 cycle? Hmm. That means my shared dependency patch cannot go in, nor anything I do about shared row locking. Fortunately that leaves the multitable truncate and the C install replacement free to be applied. -- Alvaro Herrera ([EMAIL PROTECTED]) You liked Linux a lot when he was just the gawky kid from down the block mowing your lawn or shoveling the snow. But now that he wants to date your daughter, you're not so sure he measures up. (Larry Greenemeier) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
[HACKERS] Viewupdate: Inherit default expressions from columns
For automatic view update rules we are planning to implement column default value inheritance, so that the view's column definition inherits from their base table columns (and nobody has to use an explicit ALTER TABLE view ALTER col SET DEFAULT ... ). Note that we will do that only for views, which are updateable (means that we can create rules for that view). I wonder if there are any side effects, like security issues or other stuff that will be broken by that (nothing comes currently to my mind, besides the fact that ALTERing the base tables default expression later won't be triggered to the view.). What does folks think about that, any comments? -- Bernd ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] buildfarm enhancements
I have made a new release of buildfarm client code, which has some small bug fixes and enhancements, and also has the substantial changes necessary to allow the client to run on Windows. That client can be obtained from http://pgfoundry.org/frs/?group_id=140 I have also made some modest changes to the web site - the main status dashboard page no longer shows results older than 30 days - that way if a client goes silent for some reason we aren't clogged forever. By contrast, the history page for each member/branch now lists up to the last 240 builds, rather than just the last 30 - so we can go quite a long way back if necessary. cheers andrew ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] psql 8.0 final not working on NT 4.0sp6
Magnus Hagander wrote:
According to this: http://support.microsoft.com/kb/q165695/ Windows
Desktop update was included with IE 4, but not with IE 5 or later.
Further, if you want to install Windows Desktop Update you have to
first remove IE 5 or later. And finally it says that Windows Desktop
Update can only be installed using the IE 4 setup, but this is no
longer available from Microsoft. What a mess.
Yikes. that's certainly a mess. I see the following options
Hello, Magnus. I read the -bugs thread that resulted in this code and
choose not to comment since I thought that perhaps my understanding of
the implications of using SHFolder.dll v. Shell32.dll was in error.
However, installer code that I had authored before that works on both
98, XP, and NT does:
module = LoadLibrary(SHFolder.dll);
if (module != NULL) {
getfolderv1 = GetProcAddress(module, SHGetFolderPathA);
...
invoke function, deal with ANSI path
...
FreeLibrary(module);
} else {
module = LoadLibrary(shell32.dll);
if (module != NULL) {
getfolderv2 = GetProcAddress(module, SHGetSpecialFolderLocation);
...
invoke function, deal with UNICODE path
...
FreeLibrary(module);
} else {
throw an exception here...
}
}
I think the way to guarantee success is to ship the redistributable dll,
shfolder.dll with the application, which would eliminate the need to try
and fall back to shell32.dll. shfolder.dll is redistributable:
http://www.microsoft.com/downloads/details.aspx?FamilyID=6ae02498-07e9-48f1-a5d6-dbfa18d37e0fDisplayLang=en
This article explains what needs to be done to write an installer for
older platforms:
http://support.microsoft.com/default.aspx?scid=kb%3BEN-US%3B227051
Note:
Important: SHGetFolderPath is new to the Windows 2000 API. If you call
SHGetFolderPath from an application that can be installed on a previous
version of Windows, then you will need to redistribute the file
SHFolder.dll with your application.
as does this one:
http://support.microsoft.com/default.aspx?scid=kb%3BEN-US%3BQ241733
My code expects to find an shfolder.dll on Windows 2000 systems and a
shell32.dll on = Windows 2000 systems. As I said, I *believe* you can
guarantee success by just shipping shfolder.dll with the application.
Hope that helps,
Mike Mascari
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
Re: [HACKERS] ARC patent
Neil Conway [EMAIL PROTECTED] writes: On Mon, 2005-01-17 at 18:43 -0500, Tom Lane wrote: I have already suggested to core that we should insist on 8.1 not requiring an initdb, so as to ensure that people will migrate up to it easily from 8.0. So is it firm policy that changes that require a catversion update cannot be made during the 8.1 cycle? Not yet --- I suggested it but didn't get any yeas or nays. I don't feel this is solely core's decision anyway ... what do the assembled hackers think? (Needless to say, it would be good to get this sorted out early on in the 8.1 development cycle, to avoid the need to revert patches at some point down the line. For those of us working on large projects that will definitely require an initdb, it would also be good to know -- as this policy will likely prevent that work from getting into 8.1) Yes, it has to be decided one way or the other soon. One way to have our cake and eat it too would be for someone to resurrect pg_upgrade during this devel cycle. Anyone feel like working on that? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Viewupdate: Inherit default expressions from columns
Bernd Helmle [EMAIL PROTECTED] writes: For automatic view update rules we are planning to implement column default value inheritance, so that the view's column definition inherits from their base table columns (and nobody has to use an explicit ALTER TABLE view ALTER col SET DEFAULT ... ). Note that we will do that only for views, which are updateable (means that we can create rules for that view). Just so you un-break pg_dump afterwards. regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[HACKERS] OS/2 port
I submitted the patches and additional files for the OS/2 port on the patches ML. I might as well claim responsibility for that port and put myself down as the maintainer... Lorne Sunley Winnipeg MB Canada -- --- [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] ARC patent
On Tue, 2005-01-18 at 23:26 -0500, Tom Lane wrote: Not yet --- I suggested it but didn't get any yeas or nays. I don't feel this is solely core's decision anyway ... what do the assembled hackers think? I'm not sure it's a great idea. I'm not aware of a recent example of short development cycles working well in this project. That isn't to say we *can't* do one effectively, just that history is not on our side (does anyone recall the plans to finish off Win32 in 7.5 and get it out the door quickly?) The primary justification I've heard for the no-initdb policy is that it would provide a smooth upgrade path for 8.0 users if/when the ARC patent is granted. I don't think this is the best way to deal with the ARC issue: it seems silly to handicap an entire development cycle because of one (potential) problem. Not to mention that it's not even certain whether an ARC replacement will be needed: we might be able to adapt the existing code to workaround the patent, the patent might not be granted, or IBM might grant us a license to use it. It's also worth emphasizing that this would be a rather severe limitation on what kind of new developments can go into 8.1. I think the proper fix for the ARC issue is an 8.0.x release with a new replacement policy. To avoid introducing instability into 8.0, we should obviously test the new buffer replacement policy *very* carefully. However, I think the ARC replacement should *not* be a fundamental change in behavior: the algorithm should still attempt to balance recency and frequency, to adjust dynamically to changes in workload, to avoid sequential flooding, and to allow constant-time page replacement. Ideally the ARC replacement would do something similar to ARC but via a different means. If such a patch were developed, I don't think it would be a herculean task to include it in an 8.0.x release after a lot of careful testing and code review. -Neil ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] ARC patent
Neil Conway [EMAIL PROTECTED] writes: On Tue, 2005-01-18 at 23:26 -0500, Tom Lane wrote: Not yet --- I suggested it but didn't get any yeas or nays. I don't feel this is solely core's decision anyway ... what do the assembled hackers think? I'm not aware of a recent example of short development cycles working well in this project. Granted, but we haven't tried very hard either. I think the proper fix for the ARC issue is an 8.0.x release with a new replacement policy. To avoid introducing instability into 8.0, we should obviously test the new buffer replacement policy *very* carefully. That testing isn't going to magically appear from somewhere. Unless the proposed fix is only a very small variation on what we have (which seems unlikely to get around the patent), I wouldn't have any confidence in it until it's at least survived an 8.1 beta cycle. So I don't believe in the concept of a near-term 8.0.x fix while 8.1 slides along on a slow devel schedule. What this really boils down to is whether we think we have order-of-a-year before the patent is issued. I'm nervous about assuming that. I'd like to have a plan that will produce a tested, credible patch in less than six months. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] ARC patent
... not even certain whether an ARC replacement will be needed: we might be able to adapt the existing code to workaround the patent, the patent might not be granted, or IBM might grant us a license to use it. It's also worth emphasizing that this How about contacting IBM to see where they stand on the issue...? You never know,... We might get the licence and be able to put the dusussion to rest! ... John ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
