Tom Lane wrote:
Emmanuel Cecchet writes:
But when the transaction prepares, we know that. What would prevent us
to do at prepare time the same cleanup that commit does?
The entire point of PREPARE is that it's *not* committed yet.
Agreed but all objects that were created and droppe
Emmanuel Cecchet writes:
> But when the transaction prepares, we know that. What would prevent us
> to do at prepare time the same cleanup that commit does?
The entire point of PREPARE is that it's *not* committed yet.
regards, tom lane
--
Sent via pgsql-hackers mailin
Tom Lane wrote:
Emmanuel Cecchet 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 tran
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
Emmanuel Cecchet 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 don
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
Tom Lane wrote:
Emmanuel Cecchet writes:
Take PG 8.3.0 and try:
BEGIN;
CREATE TEMP TABLE foo (x int) ON COMMIT DROP;
PREPARE TRANSACTION 't1';
[BEGIN;] <-- doesn't really matter if you start a new transaction or not
CREATE TEMP TABLE foo (x int); <-- blocks until t1 commits
I have been
Emmanuel Cecchet writes:
> Tom Lane wrote:
>> AFAIK that doesn't really have anything to do with the temp-ness of the
>> table; it'd be the same with a regular table. The problem is you have
>> an in-doubt tuple in pg_class for pg_temp_NNN.foo, and you are trying
>> to create another one for the
Emmanuel Cecchet writes:
> Take PG 8.3.0 and try:
> BEGIN;
> CREATE TEMP TABLE foo (x int) ON COMMIT DROP;
> PREPARE TRANSACTION 't1';
> [BEGIN;] <-- doesn't really matter if you start a new transaction or not
> CREATE TEMP TABLE foo (x int); <-- blocks until t1 commits
> I have been tracking dow
Hi,
As we discussed during PGCon, we are using temp tables in 2PC
transactions. The temp tables are dropped before PREPARE (or have an ON
COMMIT DROP option) and never cross transaction boundaries.
In 8.3.1, a patch was introduced to disallow temp tables in 2PC
transactions and we tried to pro
10 matches
Mail list logo
