Re: [HACKERS] OSSP can be used in the windows environment now!
Hi. - Original Message - From: "Tom Lane" <[EMAIL PROTECTED]> I'd like somebody to close the loop with upstream OSSP authors first. If they don't see anything broken about the makefile, and indicate intention to incorporate it in some future release, then it's okay to put it in our CVS temporarily. If they don't like it then we'd better understand why. There's also the possibility that they put out a release including it next week, in which case we hardly need it in our CVS. Um, I was hesitating the proposal by the reason which is not beautiful. However, it turns out that it is solvable by a little working hours. Therefore, It is due for me to do the work.I think, It is because of the wonderfulness of PostgreSQL. But, since MinGW+GCC can already be used, the problem is whether to provide by pginstaller. then, we have intension necessity in it. Then, An objection will not realize it. Regards, Hiroshi Saito ---(end of broadcast)--- TIP 1: 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] "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables
"Heikki Linnakangas" <[EMAIL PROTECTED]> writes: > I think I see what's happening here. We have restricted two-phase commit > so that you're not supposed to be able to PREPARE TRANSACTION if the > transaction has touched any temporary tables. That's because the 2nd > phase commit can be performed from another backend, and another backend > can't mess with another backend's temporary tables. > However in this case, where you CREATE and DROP the temporary table in > the same transaction, we don't detect that, and let the PREPARE > TRANSACTION to finish. The detection relies on the lock manager, but > we're not holding any locks on the dropped relation. This explanation is nonsense; we certainly *are* holding a lock on any relation that's about to be dropped. Experimentation shows that AccessExclusiveLock is indeed held (you can see it in pg_locks), but nonetheless the PREPARE doesn't complain. Did you trace through exactly why? I'm dissatisfied with the proposed patch because I'm afraid it's patching a symptom rather than whatever the real problem is. regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [HACKERS] "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables
I wrote: > This explanation is nonsense; we certainly *are* holding a lock on any > relation that's about to be dropped. Experimentation shows that > AccessExclusiveLock is indeed held (you can see it in pg_locks), but > nonetheless the PREPARE doesn't complain. Did you trace through > exactly why? I looked into this, and the problem is in LockTagIsTemp: it checks whether a lock is on a temp table this way: if (isTempOrToastNamespace(get_rel_namespace((Oid) tag->locktag_field2))) return true; What is happening is that get_rel_namespace fails to find the syscache entry for the table's pg_class row (which is expected since it's already been deleted as far as this transaction is concerned). It silently returns InvalidOid, and then isTempOrToastNamespace returns false, and so we mistakenly conclude the lock is not on a temp object. This coding had bothered me all along because I didn't care for doing a lot of syscache lookups during transaction commit, but I hadn't realized that it was outright wrong. I think we need some better means of recording whether a lock is on a temp object. We could certainly add a flag to the LOCALLOCK struct, but it's not clear where a clean place to set it would be. As a rule we don't yet know when locking a relation whether it's temp or not. regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Fwd: [HACKERS] "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables
For the list this time. -- Forwarded message -- From: Gurjeet Singh <[EMAIL PROTECTED]> Date: Fri, Feb 29, 2008 at 8:30 PM Subject: Re: [HACKERS] "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables To: Heikki Linnakangas <[EMAIL PROTECTED]> On Fri, Feb 29, 2008 at 6:54 PM, Heikki Linnakangas <[EMAIL PROTECTED]> wrote: > Gurjeet Singh wrote: > > Try the following link (I had to wait for 50 sec for the link to appear, > but > > I guess the trade-off of getting knowledge in return is worth it :) ) > > > > > http://www5.upload2.net/download/77fa86e16a02e52fd5439c76e148d231/47c7fdce/rfsLfnuVlYjEcCJ/basetables.tgz > > Thanks, that works. Can you get a working link / send over the other > file as well, please? Here you go... http://www5.upload2.net/download/afc87cfc978f2d68542e0229307829a2/47c818bd/gADZqQvOIntLRpI/insert.tgz The actual attachment follows in the next mail. Best regards, -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | indiatimes | yahoo }.com EnterpriseDB http://www.enterprisedb.com 17° 29' 34.37"N, 78° 30' 59.76"E - Hyderabad 18° 32' 57.25"N, 73° 56' 25.42"E - Pune * 37° 47' 19.72"N, 122° 24' 1.69" W - San Francisco http://gurjeet.frihost.net Mail sent from my BlackLaptop device -- [EMAIL PROTECTED] [EMAIL PROTECTED] gmail | hotmail | indiatimes | yahoo }.com EnterpriseDB http://www.enterprisedb.com 17° 29' 34.37"N, 78° 30' 59.76"E - Hyderabad 18° 32' 57.25"N, 73° 56' 25.42"E - Pune * 37° 47' 19.72"N, 122° 24' 1.69" W - San Francisco http://gurjeet.frihost.net Mail sent from my BlackLaptop device
Re: [HACKERS] "could not open relation 1663/16384/16584: No such file or directory" in a specific combination of transactions with temp tables
I wrote: > I think we need some better means of recording whether a lock is on a > temp object. We could certainly add a flag to the LOCALLOCK struct, > but it's not clear where a clean place to set it would be. As a rule > we don't yet know when locking a relation whether it's temp or not. Actually ... why are we using the lock manager to drive this at all? Temp-ness of relations is not really something that it has any interest in. What if we get rid of LockTagIsTemp altogether, and instead protect 2PC transactions by having a global flag "transactionUsedTempTable"? We could clear that at transaction start, and conditionally set it in relation_open, for very little cost. I think the idea behind the lock-manager approach was to avoid expending any cycles at all on this consideration if you weren't using 2PC. But if we have to take special action to mark locks as temp when they are taken, we certainly aren't going to beat a simple flag for performance. regards, tom lane ---(end of broadcast)--- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate
