From: | Emmanuel Cecchet <manu(at)frogthinker(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Locks on temp table and PREPARE |
Date: | 2009-06-03 21:29:30 |
Message-ID: | 4A26EB3A.7070400@frogthinker.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Emmanuel Cecchet <manu(at)frogthinker(dot)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)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-06-03 21:33:03 | Re: Locks on temp table and PREPARE |
Previous Message | Tom Lane | 2009-06-03 21:24:23 | Re: Plan time Improvement - 64bit bitmapset |