Tom Lane wrote:
> Emmanuel Cecchet <manu@frogthinker.org> writes:
>
>> Tom Lane wrote:
>>
>>> 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.
>>>
>
>
>> Please excuse my ignorance. I am not sure to get how the tuple could
>> still be live to some snapshots after the transaction has prepared.
>>
>
> Well, it couldn't be because there are no snapshots in that transaction
> anymore. The problem is that the *other* transaction doesn't have a
> good way to know that. It just sees an open transaction with
> conflicting unique-index changes.
>
But when the transaction prepares, we know that. What would prevent us
to do at prepare time the same cleanup that commit does?
regards, manu (indentation (C) tom lane)
