| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Emmanuel Cecchet <manu(at)frogthinker(dot)org> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Locks on temp table and PREPARE |
| Date: | 2009-06-03 21:01:34 |
| Message-ID: | 24760.1244062894@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2009-06-03 21:05:38 | Re: Postgres delays function returning large set of data |
| Previous Message | Alvaro Herrera | 2009-06-03 21:01:31 | Re: Locks on temp table and PREPARE |