"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
