Re: Locks on temp table and PREPARE

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)

In response to

Responses

Browse pgsql-hackers by date

  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