Emmanuel Cecchet <manu@frogthinker.org> writes:
> Tom Lane wrote:
>> AFAIK that doesn't really have anything to do with the temp-ness of the
>> table; it'd be the same with a regular table. The problem is you have
>> an in-doubt tuple in pg_class for pg_temp_NNN.foo, and you are trying
>> to create another one for the same schema/relname, and so the unique
>> index check is blocking to see what happens to the other transaction
>> that's creating/deleting the conflicting tuple.
> There should not be a doubt about table foo because whether the
> transaction commits or rollbacks, that table will not exist anymore (we
> can get rid of it at prepare time actually).
True, but the problem is that the tuple might still be live to (some
snapshots in) that transaction, so we can't inject a duplicate tuple
without risking confusing it. In this particular case that isn't an
issue because the transaction is done executing, but the tqual.c
rules don't know that.
regards, tom lane
