Added to TODO:
* Allow prepared transactions with temporary tables created and dropped
in the same transaction, and when an ON COMMIT DELETE ROWS temporary
table is accessed
http://archives.postgresql.org/pgsql-hackers/2008-03/msg00047.php
Bruce Momjian wrote:
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
John Smith wrote:
[3] I am not certain how widespread they might be, but I think there
may be some backward compatibility concerns with the patch you are
proposing.
Well, the current behavior is certainly
John Smith wrote:
BTW, I found a easier way of reproducing this (see attached 2pc.sql).
It might help with debugging or verifying a fix/regression.
Thanks.
[1] The data file is reported missing in the second transaction only
if the first transaction was ended using PREPARE TRANSACTION. The
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually ... why are we using the lock manager to drive this at all?
Good question. It has always seemed a bit strange to me. The assumption
that we always hold the lock on temp table until end of transaction,
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Looking back, I think it was driven by the desire to tie the behavior
directly to things that are going to get persisted, such as locks.
From that standpoint your initial patch to attach a temp-check to
relation-drop 2PC entries
Heikki Linnakangas [EMAIL PROTECTED] writes:
John Smith wrote:
[3] I am not certain how widespread they might be, but I think there
may be some backward compatibility concerns with the patch you are
proposing.
Well, the current behavior is certainly broken, so an application
relying on it
Tom Lane wrote:
Heikki Linnakangas [EMAIL PROTECTED] writes:
John Smith wrote:
[3] I am not certain how widespread they might be, but I think there
may be some backward compatibility concerns with the patch you are
proposing.
Well, the current behavior is certainly broken, so an
Tom Lane wrote:
I wrote:
I think we need some better means of recording whether a lock is on a
temp object. We could certainly add a flag to the LOCALLOCK struct,
but it's not clear where a clean place to set it would be. As a rule
we don't yet know when locking a relation whether it's temp
Heikki Linnakangas escribió:
In the future, it would be nice to relax the restriction on using temp
rels, though. A flag doesn't lend itself to that easily, but I'm sure
we'll figure out something if we ever get around to implement that.
I can't recall the rationale for this limitation.
Heikki Linnakangas [EMAIL PROTECTED] writes:
Tom Lane wrote:
Actually ... why are we using the lock manager to drive this at all?
Good question. It has always seemed a bit strange to me. The assumption
that we always hold the lock on temp table until end of transaction,
while true today,
Tom Lane wrote:
Do you want to write up a flag-based patch, or shall I?
I can do that.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your Subscription:
On Mon, Mar 3, 2008 at 8:46 AM, Heikki Linnakangas
[EMAIL PROTECTED] wrote:
Tom Lane wrote:
Do you want to write up a flag-based patch, or shall I?
I can do that.
BTW, I found a easier way of reproducing this (see attached 2pc.sql).
It might help with debugging or verifying a
Heikki Linnakangas [EMAIL PROTECTED] writes:
I think I see what's happening here. We have restricted two-phase commit
so that you're not supposed to be able to PREPARE TRANSACTION if the
transaction has touched any temporary tables. That's because the 2nd
phase commit can be performed from
I wrote:
This explanation is nonsense; we certainly *are* holding a lock on any
relation that's about to be dropped. Experimentation shows that
AccessExclusiveLock is indeed held (you can see it in pg_locks), but
nonetheless the PREPARE doesn't complain. Did you trace through
exactly why?
For the list this time.
-- Forwarded message --
From: Gurjeet Singh [EMAIL PROTECTED]
Date: Fri, Feb 29, 2008 at 8:30 PM
Subject: Re: [HACKERS] could not open relation 1663/16384/16584: No such
file or directory in a specific combination of transactions with temp
tables
To: Heikki
I wrote:
I think we need some better means of recording whether a lock is on a
temp object. We could certainly add a flag to the LOCALLOCK struct,
but it's not clear where a clean place to set it would be. As a rule
we don't yet know when locking a relation whether it's temp or not.
John Smith wrote:
Architecture: Intel Core 2 Duo
OS: linux-2.6.20-gentoo-r8
Filesystem: ext3
Postgres v8.2.3 compiled with gcc 4.1.1-r3
RAM - 2GB
Shared buffers - 24MB
[All other Postgres configuration parameters are default values]
Problem description:
COPY into temp table fails using a
Heikki Linnakangas wrote:
Attached is a simple patch to fix that by disallowing
CREATE+DROP+PREPARE TRANSACTION more reliably.
That patch was missing changes to header files. New patch attached.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Index:
Plausible theory, and nice explanation
Try the following link (I had to wait for 50 sec for the link to appear, but
I guess the trade-off of getting knowledge in return is worth it :) )
http://www5.upload2.net/download/77fa86e16a02e52fd5439c76e148d231/47c7fdce/rfsLfnuVlYjEcCJ/basetables.tgz
Gurjeet Singh wrote:
Plausible theory, and nice explanation
Try the following link (I had to wait for 50 sec for the link to appear, but
I guess the trade-off of getting knowledge in return is worth it :) )
Architecture: Intel Core 2 Duo
OS: linux-2.6.20-gentoo-r8
Filesystem: ext3
Postgres v8.2.3 compiled with gcc 4.1.1-r3
RAM - 2GB
Shared buffers - 24MB
[All other Postgres configuration parameters are default values]
Problem description:
COPY into temp table fails using a specific combination of
21 matches
Mail list logo
