From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Emmanuel Cecchet <manu(at)frogthinker(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Locks on temp table and PREPARE |
Date: | 2009-06-03 21:01:31 |
Message-ID: | 20090603210131.GT7172@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Emmanuel Cecchet wrote:
> 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. What
> could still happen to objects that were only visible to a transaction
> after it has prepared? An example would definitely help.
The classic example is having an open cursor that references the table.
(In this case it doesn't work, but the snapshot management module and
tqual.c don't know it.) If you want this to work you need to improve
those modules, and who knows what else ...
--
Alvaro Herrera http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-06-03 21:01:34 | Re: Locks on temp table and PREPARE |
Previous Message | Tom Lane | 2009-06-03 20:50:49 | Improving the ngettext() patch |