Re: [HACKERS] Concurrent free-lock
Ühel kenal päeval (kolmapäev, 26. jaanuar 2005, 13:30+1100), kirjutas Neil Conway: Simon Riggs wrote: The one factor which stands out for me from this is that Keir Fraser's and Tim Harris' algorithms are available as *code*, which additionally are covered by a licence which appears to be an MIT/BSD variant licence. If you're referring to their Lock-free library, that is licensed under the GPL. That's great news, as it removes one of my greatest fears from reading this thread - namely that there is a submarine patent on their algorithms waiting to surface. One of GPL's requirements is free grant of patent use. But it may be that the free patent grant applies only to GPL code, so we may be back to the problems we are struggling in ARC vs. LRU ;( -- Hannu Krosing [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] Patent issues and 8.1
On Wed, 2005-01-26 at 02:09, Neil Conway wrote:
Tom Lane wrote:
This may be the right path to go for
8.0.* ... but we must NOT suppose that we can just push it out without
a full beta test cycle.
Yeah, I think a beta period would be a good idea (not nearly as long as
the 8.0 beta period was, though).
I think it would be better to have a few weeks of beta prior to 8.0.2
and resolve the problem here and now, rather than crippling the 8.1
cycle (as the no-initdb policy would) or waiting for the problem to
*really* become serious (as the no action needed now policy would).
I don't think it is worth breaking the expectation that only minor
changes get committed in revision level releases even with a beta. I
especially hate to think about support and tuning information that has
the potential to be quit different depending on if your running 8.0.1 or
8.0.2 or some such division.
I still feel a better plan is to use the short dev cycle for 8.1 to
replace ARC and include any non-initdb changes and to branch an 8.2 now
if people with initdb changes don't want to wait to do further
development. This allows people to move away from arc using a proper
release with out having to do dump/reload; certainly the path of least
resistance for users. It is also cleaner for folks in non-patent
countries.
Of course this isn't something that has to be fixed in the next 4
months... if enough initdb level changes are close now, we could commit
to a 6 month initdb/arc replace dev cycle followed by a 3 month beta for
8.1 and release before the end of the year. That might be best anyway
since I think we probably have 3-4 major changes already waiting to go
that can certainly be finished within 6 months (2PC, autovacuum, Devrims
work, ARC replacement, potential pitr replication changes) which would
be plenty enough to warrant a new release. It's not as good as the
8.1/8.2 plan but better than the 8.0.x plan (IMHO).
Robert Treat
--
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] Allow GRANT/REVOKE permissions to be applied to all schema objects with one command
TODO1: Allow GRANT/REVOKE permissions to be applied to all schema objects with one command. TODO2: Assign Permissions to schemas wich get automatically inherited by objects created in the schema. a) should we pursue both of them? b) how can a syntax for TODO1 look like? Anchored at 'GRANT ... ON SCHEMA' or 'GRANT ... ON objecttype' ? I vote no on a. Reason: it's relatively easy to do the same thing already. However if you do end up doing that, I'd suggest using 'CASCADE'. This is reasonably consistent with other dependency honoring commands in pg. What I would really like to see is TODO2: because this allows greater flexibility for controlling security. This is impossible in pg currently, and may be a slightly more sophisticated job. Good luck! Merlin ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Deferrable Unique Constraints
Greg Stark [EMAIL PROTECTED] writes: I don't see how you're in the clear. If session A does an insert and it doesn't see a duplicate and doesn't commit, but then B does an insert and sees the duplicate from A and marks his tentative, and then commits, shouldn't B's commit succeed? No. B, being the second to get there, has to wait to see if A commits or not. This is true already and it wouldn't change. We would however postpone the wait until B's commit time. 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
[HACKERS] strange 'vacuum verbose analyze' behaviour
Hi there, we have a table with 500mln rows: wsdb=# \d usno Table public.usno Column | Type | Modifiers ++--- ra | real | dec| real | bmag | real | rmag | real | ipix | bigint | Indexes: ipix_ind btree (ipix) radec_idx1 btree (ra, dec) postgresql is a v8.0 release running on Linux 2.6.7 Day ago we run 'vacuum verbose analyze;' and now we're observing strange output (see below). We see many repeated passes through the table 'usno' and all indices (2). The only change is a string like: INFO: index radec_idx1 now contains 1024770075 row versions in 2946824 pages ^^ The loop is: usno table ~ 20sec index radec_idx1 ~ 5100sec index ipix_ind~ 1000sec and it repeated about 13 times ( 26hours/2hours ) Is this an expected behaviour or I miss something ? === CPU 120.71s/459.94u sec elapsed 5135.44 sec. INFO: index ipix_ind now contains 526280881 row versions in 1443010 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 66.65s/229.44u sec elapsed 1003.02 sec. INFO: usno: removed 2796013 row versions in 17809 pages DETAIL: CPU 1.45s/1.79u sec elapsed 17.77 sec. INFO: index radec_idx1 now contains 1024770075 row versions in 2946824 pages DETAIL: 2796013 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 147.80s/500.09u sec elapsed 5343.77 sec. INFO: index ipix_ind now contains 526280881 row versions in 1443010 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 66.99s/228.63u sec elapsed 1005.83 sec. INFO: usno: removed 2796013 row versions in 17809 pages DETAIL: CPU 1.41s/1.89u sec elapsed 19.37 sec. INFO: index radec_idx1 now contains 1021974062 row versions in 2946824 pages DETAIL: 2796013 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 152.17s/507.50u sec elapsed 5307.60 sec. INFO: index ipix_ind now contains 526280881 row versions in 1443010 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 67.38s/228.16u sec elapsed 1004.35 sec. INFO: usno: removed 2796013 row versions in 17809 pages DETAIL: CPU 1.53s/1.75u sec elapsed 18.18 sec. INFO: index radec_idx1 now contains 1019178049 row versions in 2946824 pages DETAIL: 2796013 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 131.59s/473.23u sec elapsed 5198.25 sec. INFO: index ipix_ind now contains 526280881 row versions in 1443010 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 69.60s/231.15u sec elapsed 1004.39 sec. INFO: usno: removed 2796013 row versions in 17809 pages DETAIL: CPU 1.50s/1.83u sec elapsed 19.18 sec. INFO: index radec_idx1 now contains 1016382036 row versions in 2946824 pages DETAIL: 2796013 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 120.82s/457.42u sec elapsed 5137.68 sec. INFO: index ipix_ind now contains 526280881 row versions in 1443010 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 67.00s/228.01u sec elapsed 1000.84 sec. INFO: usno: removed 2796013 row versions in 17809 pages DETAIL: CPU 1.55s/1.73u sec elapsed 19.84 sec. INFO: index radec_idx1 now contains 1013586023 row versions in 2946824 pages DETAIL: 2796013 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 114.79s/444.80u sec elapsed 5113.45 sec. INFO: index ipix_ind now contains 526280881 row versions in 1443010 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 66.73s/228.66u sec elapsed 1006.17 sec. INFO: usno: removed 2796013 row versions in 17809 pages DETAIL: CPU 1.49s/1.69u sec elapsed 20.00 sec. INFO: index radec_idx1 now contains 1010790010 row versions in 2946824 pages DETAIL: 2796013 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 114.04s/442.33u sec elapsed 5080.93 sec. INFO: index ipix_ind now contains 526280881 row versions in 1443010 pages DETAIL: 0 index row versions were removed. 0 index pages have been deleted, 0 are currently reusable. CPU 67.12s/228.84u sec elapsed 1010.20 sec. INFO: usno: removed 2796013 row versions in 17809 pages DETAIL: CPU 1.50s/1.82u sec elapsed 19.98 sec. Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
Re: [HACKERS] Deferrable Unique Constraints
Alvaro Herrera [EMAIL PROTECTED] writes: It's only a SMOC, nothing difficult AFAICS. Disk-spilling logic included, because it'd be probably needed. The question of disk-spilling is really the only part that seems very hard. It would be useful to see if we could solve the problem of spilling pending-trigger-event lists at the same time. Common infrastructure possible, perhaps? regards, tom lane ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Patent issues and 8.1
Robert Treat [EMAIL PROTECTED] writes: I don't think it is worth breaking the expectation that only minor changes get committed in revision level releases even with a beta. Ordinarily I would agree with you, but what happens to someone who is still running 8.0.* when IBM's patent gets issued? (It seems very likely to me that the patent will be issued before 8.0 disappears from the wild.) We really have to have an answer for that, and that means that an algorithm change has to get back-patched into 8.0.*. I'm coming around to the viewpoint that we should do this as a back-patch rather than try to release a file-compatible 8.1. The reason is that people who are hesitant to move up to a new release are hesitant not only because of dump/reload costs; they also worry about whether a new version will break their existing applications. If 8.1 has a pile of new features, or even simple behavioral changes such as flipping the with_oids default, then it will look like a hazard to them even without a dump/reload cycle. What's really being debated here is how we can have adequate confidence in a change that is admittedly larger than we like to back-patch. It's not an unprecedented thing mind you; we have back-patched some fairly large bug fixes in the past. But it's a bit galling to be taking any such risk for purely legal rather than technical reasons. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Patent issues and 8.1
On Thu, 27 Jan 2005, Tom Lane wrote: What's really being debated here is how we can have adequate confidence in a change that is admittedly larger than we like to back-patch. It's not an unprecedented thing mind you; we have back-patched some fairly large bug fixes in the past. But it's a bit galling to be taking any such risk for purely legal rather than technical reasons. How hard would it be to do as several have suggested already ... abstract out the ARC/LRU stuff into an API? Then, we wouldn't have to remove ARC, per se, only shift it? Wouldn't that be a smaller patch overall? Then, for our non-US users, they could continue to use ARC even after the patent (myself included), while a plug-in replacement could be available for US users? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(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] Patent issues and 8.1
Marc G. Fournier [EMAIL PROTECTED] writes: How hard would it be to do as several have suggested already ... abstract out the ARC/LRU stuff into an API? That was basically my objection to Neil's draft patch: it didn't make any effort to abstract out a cleaner API. I'll try to look into this after we have the security releases out of the way. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] [pgsql-hackers] Patent issues and 8.1
Marc, Tom, Robert, Bruce, et al: Bruce is advocating waiting until the Patent has been Granted, instead of doing something about it now, when we know the patent is going through the system (and will likely get granted) ... a reactive vs proactive response to the problem. No, we're reactive regardless. Proactive would have been to investigate the ARC paper when it was published for outstanding patent applications, and again before feature freeze. Or even to have considered the fact that when an IBM person publishes a paper on new technology, IBM probably has a patent on it ... they're the largest patent-holder in the world, after all. It's a little late for that, and would probably not even have been a good idea, lest we let legal concerns paralyze development. Basically, after the patent is granted, we are going to scramble to get rid of the ARC stuff, instead of taking the time leadign up to the granting to get rid of it so that when granted, it isn't something we have to concern ourselves with ... We don't *have* to do anything when the patent is granted. When we *have* to do something is when IBM sends a cease-and-desist letter to a PostgreSQL user. Not before. Tangentally, but relevant: a few years ago I was facing a potential lawsuit from a customer who had changed management and was suing all their former vendors as a path out of bankruptcy. Never having been sued before, I was inclined to panic. I called a classmate of mine who was a litigation attorney, and retained his services, and asked what I should do. First off, don't panic, he said. Have you been served yet? um, no Then don't worry about it. You may not be served. If you are served, you are likely to be able to get this dismissed. The last thing you want to do is panic and try to bargain with them now; they'll see that you're a softie and go on the attack. You've retained me, that's all you need to do now. (as it turned out, I was never served) Take a look again at the posting by Nicholai -- someone with professional experience in patents. Last I checked, nobody else on this list is a patent attorney, clerk, or IP litigation professional. 1) The patent may not be granted for another year. 2) The patent may never be granted. 3) When/if the patent is granted, its terms may have changed and we may no longer be infringing, *IF* we are now, which I have yet to see an *attorney's* opinion on. 4) IBM may put this patent in its set of GPL patents, since we are not the only OSS project using ARC. This would be a licensing headache for some of our users, but not a catastrophe. 5) Even if IBM does not OSS this patent, they may choose not to enforce it against us or other OSS projects since it would mean massively bad PR for them. Given that we're planning on replacing/overhauling ARC anyway, I really don't see that we need to do more at this time. Except maybe keep Neil's LRU-reversion patch somewhere handy in case we need it, and build a variant version and run it through tests at OSDL to see what it breaks (it would be good to do this anyway to see what, if anything, ARC is gaining us in terms of performance). Now, if one of our commercial supporting companies is worried enough about this to do something -- such as funding a hacker for a 3-month intensive better-than-ARC development stint -- then let them step up to the plate. Many of our programmers are happy to accept commercial development dollars for what is a commercial concern. Let's not steer development based on protecting what we think is protecting our commercial sponsors, when they haven't even asked us! Heck, the idea of a pluggable memory manager tickles my funny bone, even though I don't think such a thing is possible. Like *any* other piece of major software, we probably infringe on 50 different patents which we don't know about, held by a variety of parties. If we let this one *potential* patent panic us into a response we may regret later -- such as derailing 8.1 development, or releasing an insufficiently tested new version -- then some other company will threaten us with patents with malicious intent to watch us jump and scramble again. Attorneys have already said that Linux infringes several dozen outstanding patents. Do you see Linus suddenly overhauling the kernel? Dropping everthing and rushing a non-infringing, under-tested 2.8 to release? No, you don't. -- Josh Berkus Aglio Database Solutions San Francisco ---(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] WAL: O_DIRECT and multipage-writer
Hi everyone, I gave this a try with DBT-2, but got a core dump on our ia64 system. I hope this isn't a random thing, like I ran into previously. Maybe I'll try again, but postgres dumped core. Binary and core here: http://developer.osdl.org/markw/pgsql/core/2morefiles.tar.bz2 #0 FunctionCall2 (flinfo=0x0, arg1=0, arg2=0) at fmgr.c:1141 1141result = FunctionCallInvoke(fcinfo); (gdb) bt #0 FunctionCall2 (flinfo=0x0, arg1=0, arg2=0) at fmgr.c:1141 #1 0x403bdb80 in FunctionCall2 (flinfo=Cannot access memory at address 0x0 ) at fmgr.c:1141 #2 0x403bdb80 in FunctionCall2 (flinfo=Cannot access memory at address 0x0 ) at fmgr.c:1141 Over and over again, so I'll keep the backtrace short. Mark ---(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] [pgsql-hackers] Patent issues and 8.1
Josh, Bruce is advocating waiting until the Patent has been Granted, instead of doing something about it now, when we know the patent is going through the system (and will likely get granted) ... a reactive vs proactive response to the problem. Very well written Josh. Thanks. As you know, I'm getting a little sick of the chicken little act among many of the -hackers --Josh -- __Aglio Database Solutions___ Josh BerkusConsultant josh@agliodbs.comwww.agliodbs.com Ph: 415-752-2500Fax: 415-752-2387 2166 Hayes Suite 200San Francisco, CA ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] Patent issues and 8.1
Josh Berkus josh@agliodbs.com writes: No, we're reactive regardless. Proactive would have been to investigate the ARC paper when it was published for outstanding patent applications, and again before feature freeze. Or even to have considered the fact that when an IBM person publishes a paper on new technology, IBM probably has a patent on it ... they're the largest patent-holder in the world, after all. It's a little late for that, and would probably not even have been a good idea, lest we let legal concerns paralyze development. That would actually be a bad idea. As several people have pointed out, actively seeking out patents you may be infringing is risky because it can open you up to liability and that can paralyze development. We don't *have* to do anything when the patent is granted. When we *have* to do something is when IBM sends a cease-and-desist letter to a PostgreSQL user. Not before. That's untrue. I suggest you disregard all my comments as free legal advice is really only worth what you pay for it. IANAL and all that. But I also suggest you stop giving legal opinions like this. Moreover, the postgres development community is really not the concern here. Users of postgres who are aware of this issue (and many of them are on this list) will be the ones put at risk. -- greg ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] strange 'vacuum verbose analyze' behaviour
Oleg Bartunov oleg@sai.msu.su writes: Day ago we run 'vacuum verbose analyze;' and now we're observing strange output (see below). We see many repeated passes through the table 'usno' and all indices (2). Nothing strange about it: that's how vacuum deals with large tables. You can reduce the number of passes over the indexes by increasing maintenance_work_mem (aka vacuum_mem). It looks like you have that set to 16MB, which is enough to hold about 2.79M 6-byte CTIDs. When that fills up, we have to go and clean out the corresponding index entries before we resume scanning the heap. It is a bit odd that nothing is getting deleted from ipix_ind ... is that a partial index? regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Security Release Packaging ...
It is ~22:00GMT right now ... I will start the packaging process in approx. 3hrs and will announce once they are all ready ... Just to clarify, we're doing: 8.0.1 And 7.4/7.3/7.2 branches ... correct? Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] Permissions on aggregate component functions
I just noticed that there is no permission check anywhere in CREATE AGGREGATE concerning the aggregate's transition and final functions. This means anyone can trivially bypass the function EXECUTE permission check: just make an aggregate function to call it for you. (Now, this works only for functions whose signature fits what an aggregate expects, but for most one- and two-argument functions you can do it.) Clearly this is a must-fix issue, but I'm wondering exactly where the check should be enforced. Is it sufficient to check at the time of CREATE AGGREGATE that the creator has appropriate rights, or do we need to do it every time the aggregate is used? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] strange 'vacuum verbose analyze' behaviour
On Thu, 27 Jan 2005, Tom Lane wrote: Oleg Bartunov oleg@sai.msu.su writes: Day ago we run 'vacuum verbose analyze;' and now we're observing strange output (see below). We see many repeated passes through the table 'usno' and all indices (2). Nothing strange about it: that's how vacuum deals with large tables. You can reduce the number of passes over the indexes by increasing maintenance_work_mem (aka vacuum_mem). It looks like you have that set to 16MB, which is enough to hold about 2.79M 6-byte CTIDs. When that fills up, we have to go and clean out the corresponding index entries before we resume scanning the heap. thanks for info, just increased maintenance_work_mem and will see It is a bit odd that nothing is getting deleted from ipix_ind ... is that a partial index? no. wsdb=# \d ipix_ind Index public.ipix_ind Column | Type + ipix | bigint btree, for table public.usno regards, tom lane Regards, Oleg _ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83 ---(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] Security Release Packaging ...
Marc G. Fournier [EMAIL PROTECTED] writes: It is ~22:00GMT right now ... I will start the packaging process in approx. 3hrs and will announce once they are all ready ... I think we are gonna have to put it off a little bit. I haven't even started doing the release notes, and we've got a couple different must-fix-looking issues that just popped up this afternoon. Maybe we should reschedule for Sunday/Monday? regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] WAL: O_DIRECT and multipage-writer
Thanks for testing, Mark! I gave this a try with DBT-2, but got a core dump on our ia64 system. I hope this isn't a random thing, like I ran into previously. Maybe I'll try again, but postgres dumped core. Sorry, this seems to be my patch's bug. Which datatype did you compile with? LP64, ILP64, or LLP64? If you used LLP64, I think the cause is buffer alignment routine because of sizeof(long) != sizeof(void*). I'll fix it soon... ITAGAKI Takahiro ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Permissions on aggregate component functions
On Thu, Jan 27, 2005 at 15:27:54 -0500, Tom Lane [EMAIL PROTECTED] wrote: I just noticed that there is no permission check anywhere in CREATE AGGREGATE concerning the aggregate's transition and final functions. This means anyone can trivially bypass the function EXECUTE permission check: just make an aggregate function to call it for you. (Now, this works only for functions whose signature fits what an aggregate expects, but for most one- and two-argument functions you can do it.) Clearly this is a must-fix issue, but I'm wondering exactly where the check should be enforced. Is it sufficient to check at the time of CREATE AGGREGATE that the creator has appropriate rights, or do we need to do it every time the aggregate is used? I would think both would be best. If you don't check at runtime the function owner can't easily revoke access (dropping the function might be a pain if it is used in lots of places). It is nice to check at creation so as to give immediate feedback if there is a problem. ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
Re: [PATCHES] [HACKERS] WAL: O_DIRECT and multipage-writer
Hmm... I don't remember specifying a datatype. I suppose whatever the default one is. :) I'll be happy to test again, just let me know. Mark On Fri, Jan 28, 2005 at 06:28:32AM +0900, ITAGAKI Takahiro wrote: Thanks for testing, Mark! I gave this a try with DBT-2, but got a core dump on our ia64 system. I hope this isn't a random thing, like I ran into previously. Maybe I'll try again, but postgres dumped core. Sorry, this seems to be my patch's bug. Which datatype did you compile with? LP64, ILP64, or LLP64? If you used LLP64, I think the cause is buffer alignment routine because of sizeof(long) != sizeof(void*). I'll fix it soon... ITAGAKI Takahiro ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Security Release Packaging ...
On Thu, 27 Jan 2005, Tom Lane wrote: Marc G. Fournier [EMAIL PROTECTED] writes: It is ~22:00GMT right now ... I will start the packaging process in approx. 3hrs and will announce once they are all ready ... I think we are gonna have to put it off a little bit. I haven't even started doing the release notes, and we've got a couple different must-fix-looking issues that just popped up this afternoon. Maybe we should reschedule for Sunday/Monday? No arguments here ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 8: explain analyze is your friend
[HACKERS] Strange issue with initdb on 8.0 and Solaris automounts
Folks, I ran into an interesting issue when installing PostgreSQL 8.0 that I'm not sure how to resolve correctly. My system is a Sun machine (Blade 1000) running Solaris 9, with relatively recent patches. After install- ing 8.0, I went to run the 'initdb' command and was greeted with the following: [delirium:postgres] ~ (11) initdb -D /software/postgresql-8.0.0/data The files belonging to this database system will be owned by user postgres. This user must also own the server process. The database cluster will be initialized with locale C. creating directory /software/postgresql-8.0.0/data ... initdb: could not create directory /software/postgresql-8.0.0: Operation not applicable The error message was a bit confusing, so I decided to run a truss on the process to see what might be happening, and this is what I came across: [...] 8802/1: write(1, c r e a t i n g d i r.., 62) = 62 8802/1: umask(0)= 077 8802/1: umask(077) = 0 8802/1: mkdir(/software, 0777)Err#17 EEXIST 8802/1: stat64(/software, 0xFFBFC858) = 0 8802/1: mkdir(/software/postgresql-8.0.0, 0777) Err#89 ENOSYS [...] The last error in that section, ENOSYS, is very strange, as the Solaris manpage for 'mkdir' does not mention it as a possible error. One thing to note in this, however, is that '/software/postgresql-8.0.0' is not a regular directory, but an automount point (which in this case is just a local loopback mount). So the indication is that Solaris seems to have a bug not in mkdir, but deeper in their VFS code that's causing this seemingly strange issue. Two workarounds for this problem have been found: running 'initdb' with a directory that's *not* an automount point and then moving the 'data' directory to its final destination worked fine, along with a suggestion from Andrew Dunstan (on the #postgresql IRC channel) with using a rela- tive path for the data directory. Both were successful in avoiding the issue, but I decided to mention this here in case someone felt it might be worth looking into to see if the Sun problem can be avoided; I am going to notify Sun of their bug, just don't know how long it will take them to actually resolve it (if they ever do). While I can fully understand that a code change here may not be desire- able, might some notes in the documentation be useful for those who might stumble across the problem as well? Just a suggestion... I hope I gave sufficient information on the problem, though I'm always willing to give any clarification needed. Thank you for your time. Ken Lareau [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Strange issue with initdb on 8.0 and Solaris automounts
Coincidentally I JUST NOW built 8.0 on Solaris 9, and ran into the same problem. As they say, this used to work. We build databases as part of the build of our product, and I'm looking into what we need to do to upgrade from 7.4.5, and this was the first thing I ran into. I hadn't gotten as far as truss yet, so thanks Kenneth for that extra info. Did initdb previously just assume the -D path existed, and now it is trying to create the whole path, if necessary? - DAP -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Lareau Sent: Thursday, January 27, 2005 5:23 PM To: pgsql-hackers@postgresql.org Subject: [HACKERS] Strange issue with initdb on 8.0 and Solaris automounts Folks, I ran into an interesting issue when installing PostgreSQL 8.0 that I'm not sure how to resolve correctly. My system is a Sun machine (Blade 1000) running Solaris 9, with relatively recent patches. After install- ing 8.0, I went to run the 'initdb' command and was greeted with the following: [delirium:postgres] ~ (11) initdb -D /software/postgresql-8.0.0/data The files belonging to this database system will be owned by user postgres. This user must also own the server process. The database cluster will be initialized with locale C. creating directory /software/postgresql-8.0.0/data ... initdb: could not create directory /software/postgresql-8.0.0: Operation not applicable The error message was a bit confusing, so I decided to run a truss on the process to see what might be happening, and this is what I came across: [...] 8802/1: write(1, c r e a t i n g d i r.., 62) = 62 8802/1: umask(0)= 077 8802/1: umask(077) = 0 8802/1: mkdir(/software, 0777) Err#17 EEXIST 8802/1: stat64(/software, 0xFFBFC858) = 0 8802/1: mkdir(/software/postgresql-8.0.0, 0777) Err#89 ENOSYS [...] The last error in that section, ENOSYS, is very strange, as the Solaris manpage for 'mkdir' does not mention it as a possible error. One thing to note in this, however, is that '/software/postgresql-8.0.0' is not a regular directory, but an automount point (which in this case is just a local loopback mount). So the indication is that Solaris seems to have a bug not in mkdir, but deeper in their VFS code that's causing this seemingly strange issue. Two workarounds for this problem have been found: running 'initdb' with a directory that's *not* an automount point and then moving the 'data' directory to its final destination worked fine, along with a suggestion from Andrew Dunstan (on the #postgresql IRC channel) with using a rela- tive path for the data directory. Both were successful in avoiding the issue, but I decided to mention this here in case someone felt it might be worth looking into to see if the Sun problem can be avoided; I am going to notify Sun of their bug, just don't know how long it will take them to actually resolve it (if they ever do). While I can fully understand that a code change here may not be desire- able, might some notes in the documentation be useful for those who might stumble across the problem as well? Just a suggestion... I hope I gave sufficient information on the problem, though I'm always willing to give any clarification needed. Thank you for your time. Ken Lareau [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Permissions on aggregate component functions
On Thu, 2005-01-27 at 15:27 -0500, Tom Lane wrote: I just noticed that there is no permission check anywhere in CREATE AGGREGATE concerning the aggregate's transition and final functions. This means anyone can trivially bypass the function EXECUTE permission check: just make an aggregate function to call it for you. (Now, this works only for functions whose signature fits what an aggregate expects, but for most one- and two-argument functions you can do it.) Clearly this is a must-fix issue, but I'm wondering exactly where the check should be enforced. Is it sufficient to check at the time of CREATE AGGREGATE that the creator has appropriate rights, or do we need to do it every time the aggregate is used? Well spotted. Check should be once for each SQL statement in which the function is attempted to be used. Otherwise, an administrator might revoke EXECUTE privilege on a function that was used as part of an AGGREGATE, then discover that the user could still execute it in the way you suggest. -- Best Regards, Simon Riggs ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] bug w/ cursors and savepoints
Alvaro Herrera wrote: On Wed, Jan 26, 2005 at 05:10:09PM -0500, Tom Lane wrote: I don't think we have a lot of choices: we have to destroy (or at least mark FAILED) all such cursors for the time being. I don't see a lot of difference between marking the portal FAILED and destroying it (maybe I'm looking at the wrong code). So I just took the simpler approach; patch attached. I assume that you can CLOSE a failed portal, but you can't CLOSE a destroyed portal (because it's not there any more)? This is important for the JDBC driver as it creates portals internally, does fetches as the application code demands, then closes the portal at some point after the application is done with it. Having the close fail because of an intervening savepoint rollback isn't great -- the error will cause an unexpected failure of the current transaction. This can happen even if the application doesn't try to use the portal (via ResultSet) after the savepoint rollback at all. It wouldn't be so bad if the driver could track savepoint boundaries, but the current protocol doesn't make that easy.. -O ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Strange issue with initdb on 8.0 and Solaris automounts
David Parker [EMAIL PROTECTED] writes: Did initdb previously just assume the -D path existed, and now it is trying to create the whole path, if necessary? Pre-8.0 it was using mkdir(1), which might possibly contain some weird workaround for this case on Solaris. I suppose that manually creating the data directory before running initdb would also avoid this issue, since the mkdir(2) loop is only entered if we don't find the directory in existence. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] bug w/ cursors and savepoints
Oliver Jowett wrote: Having the close fail because of an intervening savepoint rollback isn't great -- the error will cause an unexpected failure of the current transaction. Never mind -- I just reread the protocol docs, and it's safe to close a nonexistant portal. Did this previously issue a warning, or something similar? I'm sure I had seen problems in this area in the past.. -O ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [HACKERS] Strange issue with initdb on 8.0 and Solaris automounts
I tried that, and it just runs into the problem with the first sub dir it tries to create: ed9i03:/home/dparker/temp % initdb -D /home/dparker/temp/testdb The files belonging to this database system will be owned by user dparker. This user must also own the server process. The database cluster will be initialized with locale C. fixing permissions on existing directory /home/dparker/temp/testdb ... ok creating directory /home/dparker/temp/testdb/global ... initdb: could not create directory /home/dparker: Operation not applicable initdb: removing contents of data directory /home/dparker/temp/testdb ed9i03:/home/dparker/temp truss: chmod(/home/dparker/temp/testdb, 0700)= 0 ok write(1, o k\n, 3) = 3 creating directory /home/dparker/temp/testdb/global ... write(1, c r e a t i n g d i r.., 56) = 56 umask(0)= 077 umask(077) = 0 mkdir(/home, 0777)Err#17 EEXIST xstat(2, /home, 0x08045C20) = 0 mkdir(/home/dparker, 0777)Err#89 ENOSYS umask(077) = 077 fstat64(2, 0x08045000) = 0 initdbwrite(2, i n i t d b, 6) = 6 : could not create directory write(2, : c o u l d n o t .., 30) = 30 /home/dparkerwrite(2, / h o m e / d p a r k e.., 13) = 13 : write(2, : , 3)= 3 Operation not applicablewrite(2, O p e r a t i o n n o.., 24) = 24 - DAP -Original Message- From: Tom Lane [mailto:[EMAIL PROTECTED] Sent: Thursday, January 27, 2005 6:22 PM To: David Parker Cc: Kenneth Lareau; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Strange issue with initdb on 8.0 and Solaris automounts David Parker [EMAIL PROTECTED] writes: Did initdb previously just assume the -D path existed, and now it is trying to create the whole path, if necessary? Pre-8.0 it was using mkdir(1), which might possibly contain some weird workaround for this case on Solaris. I suppose that manually creating the data directory before running initdb would also avoid this issue, since the mkdir(2) loop is only entered if we don't find the directory in existence. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] bug w/ cursors and savepoints
On Fri, Jan 28, 2005 at 12:27:05PM +1300, Oliver Jowett wrote: Oliver Jowett wrote: Having the close fail because of an intervening savepoint rollback isn't great -- the error will cause an unexpected failure of the current transaction. Never mind -- I just reread the protocol docs, and it's safe to close a nonexistant portal. Did this previously issue a warning, or something similar? I'm sure I had seen problems in this area in the past.. Not sure ... however I remember somebody complained because the SQL level interface differed from the protocol level one on this point. -- Alvaro Herrera ([EMAIL PROTECTED]) In a specialized industrial society, it would be a disaster to have kids running around loose. (Paul Graham) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [HACKERS] Strange issue with initdb on 8.0 and Solaris automounts
In message [EMAIL PROTECTED], Tom Lane writes: David Parker [EMAIL PROTECTED] writes: Did initdb previously just assume the -D path existed, and now it is trying to create the whole path, if necessary? Pre-8.0 it was using mkdir(1), which might possibly contain some weird workaround for this case on Solaris. I suppose that manually creating the data directory before running initdb would also avoid this issue, since the mkdir(2) loop is only entered if we don't find the directory in existence. regards, tom lane Actually, creating the 'data' directory first doesn't work either: [delirium:postgres] ~ (17) mkdir data [delirium:postgres] ~ (18) initdb -D /software/postgresql-8.0.0/data The files belonging to this database system will be owned by user postgres. This user must also own the server process. The database cluster will be initialized with locale C. fixing permissions on existing directory /software/postgresql-8.0.0/data ... ok creating directory /software/postgresql-8.0.0/data/global ... initdb: could not create directory /software/postgresql-8.0.0: Operation not applicable initdb: removing contents of data directory /software/postgresql-8.0.0/data Since there's subdirectories that need to be created, it still runs into the problem. I don't know why the command 'mkdir' doesn't exhibit the same problem as the function 'mkdir', but running: mkdir /software/postgresql-8.0.0 produces the correct error File exists on my system. I suspect the 'mkdir' command probably checks to see if the directory exists first before trying to create it, which avoids the problem. Ken Lareau [EMAIL PROTECTED] ---(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] Strange issue with initdb on 8.0 and Solaris automounts
Kenneth Lareau [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Tom Lane writes: I suppose that manually creating the data directory before running initdb would also avoid this issue, since the mkdir(2) loop is only entered if we don't find the directory in existence. Actually, creating the 'data' directory first doesn't work either: Good point. I don't know why the command 'mkdir' doesn't exhibit the same problem as the function 'mkdir', but running: mkdir /software/postgresql-8.0.0 produces the correct error File exists on my system. Could you truss that and see what it does? It would be a simple change in initdb to make it stat before mkdir instead of after, but I'm not totally convinced that would fix the problem. If mkdir returns a funny error code then stat might as well ... regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [HACKERS] Strange issue with initdb on 8.0 and Solaris automounts
In message [EMAIL PROTECTED], Tom Lane writes: Kenneth Lareau [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Tom Lane writes: I suppose that manually creating the data directory before running initdb would also avoid this issue, since the mkdir(2) loop is only entered if we don't find the directory in existence. Actually, creating the 'data' directory first doesn't work either: Good point. I don't know why the command 'mkdir' doesn't exhibit the same problem as the function 'mkdir', but running: mkdir /software/postgresql-8.0.0 produces the correct error File exists on my system. Could you truss that and see what it does? It would be a simple change in initdb to make it stat before mkdir instead of after, but I'm not totally convinced that would fix the problem. If mkdir returns a funny error code then stat might as well ... regards, tom lane Here's the relevant truss output from 'mkdir /software/postgresql-8.0.0' on my Solaris 9 system: 10832: umask(0)= 077 10832: umask(077) = 0 10832: mkdir(/software/postgresql-8.0.0, 0777) Err#89 ENOSYS 10832: stat64(/software/postgresql-8.0.0, 0xFFBFFA38) = 0 10832: fstat64(2, 0xFFBFEB78) = 0 10832: write(2, m k d i r, 5) = 5 10832: write(2, : , 2) = 2 10832: write(2, c a n n o t c r e a t.., 24) = 24 10832: write(2, ` / s o f t w a r e / p.., 28) = 28 10832: write(2, : , 2) = 2 10832: write(2, F i l e e x i s t s, 11) = 11 10832: write(2, \n, 1) = 1 10832: _exit(1) It's doing the stat after the mkdir attempt it seems, and coming back with the correct response. Hmm, maybe I should look at the Solaris 8 code for the mkdir command... Ken Lareau [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] Strange issue with initdb on 8.0 and Solaris automounts
Tom Lane wrote: I don't know why the command 'mkdir' doesn't exhibit the same problem as the function 'mkdir', but running: mkdir /software/postgresql-8.0.0 produces the correct error File exists on my system. Could you truss that and see what it does? It would be a simple change in initdb to make it stat before mkdir instead of after, but I'm not totally convinced that would fix the problem. If mkdir returns a funny error code then stat might as well ... There's also a tiny race condition, which I guess isn't worth worrying about. Returning ENOSYS is pretty bogus ... cheers andrew ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [HACKERS] Strange issue with initdb on 8.0 and Solaris automounts
Andrew Dunstan [EMAIL PROTECTED] writes: There's also a tiny race condition, which I guess isn't worth worrying about. Considering that we're not checking ownership or permissions of the parent directories, I'd say not. 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] Strange issue with initdb on 8.0 and Solaris automounts
Kenneth Lareau [EMAIL PROTECTED] writes:
In message [EMAIL PROTECTED], Tom Lane writes:
Could you truss that and see what it does?
Here's the relevant truss output from 'mkdir /software/postgresql-8.0.0'
on my Solaris 9 system:
10832: mkdir(/software/postgresql-8.0.0, 0777) Err#89 ENOSYS
10832: stat64(/software/postgresql-8.0.0, 0xFFBFFA38) = 0
It's doing the stat after the mkdir attempt it seems, and coming back
with the correct response. Hmm, maybe I should look at the Solaris 8
code for the mkdir command...
Well, the important point is that the stat does succeed. I'm not going
to put in anything as specific as a check for ENOSYS, but it seems
reasonable to try the stat first and mkdir only if stat fails.
I've applied the attached patch.
regards, tom lane
*** src/bin/initdb/initdb.c.origSat Jan 8 17:51:12 2005
--- src/bin/initdb/initdb.c Thu Jan 27 19:23:49 2005
***
*** 476,481
--- 476,484
* this tries to build all the elements of a path to a directory a la mkdir -p
* we assume the path is in canonical form, i.e. uses / as the separator
* we also assume it isn't null.
+ *
+ * note that on failure, the path arg has been modified to show the particular
+ * directory level we had problems with.
*/
static int
mkdir_p(char *path, mode_t omode)
***
*** 544,573
}
if (last)
(void) umask(oumask);
! if (mkdir(path, last ? omode : S_IRWXU | S_IRWXG | S_IRWXO) 0)
{
! if (errno == EEXIST || errno == EISDIR)
! {
! if (stat(path, sb) 0)
! {
! retval = 1;
! break;
! }
! else if (!S_ISDIR(sb.st_mode))
! {
! if (last)
! errno = EEXIST;
! else
! errno = ENOTDIR;
! retval = 1;
! break;
! }
! }
! else
{
retval = 1;
break;
}
}
if (!last)
*p = '/';
--- 547,570
}
if (last)
(void) umask(oumask);
!
! /* check for pre-existing directory; ok if it's a parent */
! if (stat(path, sb) == 0)
{
! if (!S_ISDIR(sb.st_mode))
{
+ if (last)
+ errno = EEXIST;
+ else
+ errno = ENOTDIR;
retval = 1;
break;
}
+ }
+ else if (mkdir(path, last ? omode : S_IRWXU | S_IRWXG |
S_IRWXO) 0)
+ {
+ retval = 1;
+ break;
}
if (!last)
*p = '/';
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
Re: [HACKERS] Strange issue with initdb on 8.0 and Solaris automounts
In message [EMAIL PROTECTED], Tom Lane writes: Kenneth Lareau [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Tom Lane writes: Could you truss that and see what it does? Here's the relevant truss output from 'mkdir /software/postgresql-8.0.0' on my Solaris 9 system: 10832: mkdir(/software/postgresql-8.0.0, 0777) Err#89 ENOSYS 10832: stat64(/software/postgresql-8.0.0, 0xFFBFFA38) = 0 It's doing the stat after the mkdir attempt it seems, and coming back with the correct response. Hmm, maybe I should look at the Solaris 8 code for the mkdir command... Well, the important point is that the stat does succeed. I'm not going to put in anything as specific as a check for ENOSYS, but it seems reasonable to try the stat first and mkdir only if stat fails. I've applied the attached patch. regards, tom lane Tom, thank you very much for the patch, it worked like a charm. Ken Lareau [EMAIL PROTECTED] ---(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] Patent issues and 8.1
On Thursday 27 January 2005 10:27, Tom Lane wrote:
Robert Treat [EMAIL PROTECTED] writes:
I don't think it is worth breaking the expectation that only minor
changes get committed in revision level releases even with a beta.
Ordinarily I would agree with you, but what happens to someone who is
still running 8.0.* when IBM's patent gets issued? (It seems very
likely to me that the patent will be issued before 8.0 disappears from
the wild.) We really have to have an answer for that, and that means
that an algorithm change has to get back-patched into 8.0.*.
This is a straw-man, since nothing stops people from running 8.0.0 even if the
replacement come in 8.0.1
I'm coming around to the viewpoint that we should do this as a
back-patch rather than try to release a file-compatible 8.1. The reason
is that people who are hesitant to move up to a new release are hesitant
not only because of dump/reload costs; they also worry about whether a
new version will break their existing applications. If 8.1 has a pile
of new features, or even simple behavioral changes such as flipping the
with_oids default, then it will look like a hazard to them even without
a dump/reload cycle.
Some people get scared of changes between even minor revision releases even
when we tell them it is safe to do. (Of course pushing a change like ARC out
in a minor release isn't going to help do away with that perception) Sticking
to a two-month/no-initdb cycle, I don't think we'll have to worry about
piles-of-changes that make things incompatible.
What's really being debated here is how we can have adequate confidence
in a change that is admittedly larger than we like to back-patch. It's
not an unprecedented thing mind you; we have back-patched some fairly
large bug fixes in the past. But it's a bit galling to be taking any
such risk for purely legal rather than technical reasons.
Especially when it doesn't even effect everyone involved. Or anyone... who
knows, maybe oracle is out submitting prior art and the thing never even gets
granted.
--
Robert Treat
Build A Brighter Lamp :: Linux Apache {middleware} PostgreSQL
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
Re: [HACKERS] Strange issue with initdb on 8.0 and Solaris automounts
Yes, thanks very much! - DAP -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth Lareau Sent: Thursday, January 27, 2005 8:10 PM To: Tom Lane Cc: Kenneth Lareau; pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Strange issue with initdb on 8.0 and Solaris automounts In message [EMAIL PROTECTED], Tom Lane writes: Kenneth Lareau [EMAIL PROTECTED] writes: In message [EMAIL PROTECTED], Tom Lane writes: Could you truss that and see what it does? Here's the relevant truss output from 'mkdir /software/postgresql-8.0.0' on my Solaris 9 system: 10832: mkdir(/software/postgresql-8.0.0, 0777) Err#89 ENOSYS 10832: stat64(/software/postgresql-8.0.0, 0xFFBFFA38) = 0 It's doing the stat after the mkdir attempt it seems, and coming back with the correct response. Hmm, maybe I should look at the Solaris 8 code for the mkdir command... Well, the important point is that the stat does succeed. I'm not going to put in anything as specific as a check for ENOSYS, but it seems reasonable to try the stat first and mkdir only if stat fails. I've applied the attached patch. regards, tom lane Tom, thank you very much for the patch, it worked like a charm. Ken Lareau [EMAIL PROTECTED] ---(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 ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [HACKERS] Patent issues and 8.1
On Thu, 27 Jan 2005, Robert Treat wrote: On Thursday 27 January 2005 20:47, Tom Lane wrote: Robert Treat [EMAIL PROTECTED] writes: On Thursday 27 January 2005 10:27, Tom Lane wrote: Ordinarily I would agree with you, but what happens to someone who is still running 8.0.* when IBM's patent gets issued? This is a straw-man, since nothing stops people from running 8.0.0 even if the replacement come in 8.0.1 I don't think so. It's not our responsibility if someone doesn't take advantage of an available update. But it is our responsibility if no update is available. The straw-man is that this needs to happen in 8.0.x rather than 8.1, IMHO. the 8.0.x branch is already released software, and is no longer being developed, prior to any patent happening ... the ARC changes will by no means be a bug fix, nor minor, and aren't appropriate for back patching to any of the releases, including 8.0.x ... Marc G. Fournier Hub.Org Networking Services (http://www.hub.org) Email: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send unregister YourEmailAddressHere to [EMAIL PROTECTED])
[HACKERS] storage of compiled functions
Hello everyone i have been studying postgres's function handling philosophy lately. I got stuck at a point where i could'nt get the answer myself All the information related to functions are stored in pg_proc system catalog. But when a function is compiled (probably the data structure that contains a compiled function is pgfunction) where is it stored for persistence. I checked plpgsql's code and noticed there that the function after compilation was saved in fcinfo-flinfo-fn_extra. But how do you get persistence (of compiled functions) by storing its value in fcinfo-flinfo-fn_extra. Or in other words how is the FmgrInfo information stored to persistence in postgresql Thankz ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [HACKERS] storage of compiled functions
Sibtay Abbas [EMAIL PROTECTED] writes: All the information related to functions are stored in pg_proc system catalog. But when a function is compiled (probably the data structure that contains a compiled function is pgfunction) where is it stored for persistence. It isn't. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
