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 bro
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 b
"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
> re
"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
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,
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
er
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 fix/reg
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:
http://mail.postgresql.org/mj
"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
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.
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 or
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.
Actu
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 wit
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 wh
"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 performe
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 :) )
http://www5.upload2.net/download/77fa86e16a02e52fd5439c76e148d231/47c7fdce/rfsLfnuVl
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
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: src/backend/access/tran
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 specifi
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
cre
21 matches
Mail list logo
