Stephan Szabo [EMAIL PROTECTED] writes:
On Tue, 30 Sep 2003, Tom Lane wrote:
I think I can implement it and it will act as stated in my proposal.
Whether people like the proposed behavior is the big question in my
mind.
I think it's more reasonable than the current behavior or any of
the
On Wed, 1 Oct 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
On Tue, 30 Sep 2003, Tom Lane wrote:
I think I can implement it and it will act as stated in my proposal.
Whether people like the proposed behavior is the big question in my
mind.
I think it's more reasonable
On Wed, 1 Oct 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
On Wed, 1 Oct 2003, Tom Lane wrote:
I've committed the attached patch. One thing I wanted to double-check
with you is that the SELECT FOR UPDATES done in the noaction cases are
being correctly handled.
I
Stephan Szabo [EMAIL PROTECTED] writes:
On Fri, 26 Sep 2003, Tom Lane wrote:
Hmm, that is a good point. It would be cleaner to throw a can't
serialize failure than have the RI triggers run under a different
snapshot. I am not sure if we can implement that behavior easily,
though. Can you
On Tue, 30 Sep 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
On Fri, 26 Sep 2003, Tom Lane wrote:
Hmm, that is a good point. It would be cleaner to throw a can't
serialize failure than have the RI triggers run under a different
snapshot. I am not sure if we can
Stephan Szabo wrote:
The case at hand (with *'s on the ri queries) assuming pk already
has an id=1 row would be.
T1: begin;
T1: set transaction isolation level serializable;
T1 ... (something that does a select, not necessarily on either pk or fk)
T2: begin;
T2: insert into fk values (1);
On Fri, 26 Sep 2003, Kevin Brown wrote:
Stephan Szabo wrote:
The case at hand (with *'s on the ri queries) assuming pk already
has an id=1 row would be.
T1: begin;
T1: set transaction isolation level serializable;
T1 ... (something that does a select, not necessarily on either pk or
Stephan Szabo wrote:
The problem in the scenario you described should be solved if we mark any
rows that are selected with the for update option (either implicitly,
as with RI triggers, or explicitly) as having been modified by the
selecting transaction, the equivalent of (in the case of
Okay, I'll work out some extension of the APIs to let us propagate the
snapshot request down through SPI and into the Executor, rather than
using a global variable for it. (Unless someone has a better idea...)
Just when you thought it was safe to go back in the water ...
Chris Kratz sent me
On Friday 26 September 2003 19:50, Tom Lane wrote:
Anyway, on to Chris' example. Load the attached script into a database
that has plpgsql already created, and then do
DELETE FROM Activity WHERE ActivityID = 16739;
You'll get
ERROR: attempted to mark4update invisible tuple
(or
Shridhar Daithankar [EMAIL PROTECTED] writes:
If the trigger function is precompiled, the error would not be reproducible
and it will work correctly, right?
Only because the trigger in the example doesn't issue any queries of its
own. If it did, it would cause CommandCounterIncrement(s)
On Fri, 26 Sep 2003, Tom Lane wrote:
Okay, I'll work out some extension of the APIs to let us propagate the
snapshot request down through SPI and into the Executor, rather than
using a global variable for it. (Unless someone has a better idea...)
Just when you thought it was safe to go
Stephan Szabo [EMAIL PROTECTED] writes:
I think theoretically in serializable the cases where the difference
between the snapshot from this statement and the standard snapshot for the
transaction are noticable we probably have a serialization failure
Hmm, that is a good point. It would be
On Fri, 26 Sep 2003, Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
I think theoretically in serializable the cases where the difference
between the snapshot from this statement and the standard snapshot for the
transaction are noticable we probably have a serialization failure
Tom Lane wrote:
Stephan Szabo [EMAIL PROTECTED] writes:
I think theoretically in serializable the cases where the difference
between the snapshot from this statement and the standard snapshot for the
transaction are noticable we probably have a serialization failure
Hmm, that is a good
Hello Tom,
In trying to come up with a test scenario, I loaded this db into a 7.4 db
and got a similar message. It shows up as follows:
dropsites= begin;
BEGIN
dropsites= delete from te_users where reseller = 21;
ERROR: attempted to mark4update invisible tuple
CONTEXT: PL/pgSQL function
Wade Klaver [EMAIL PROTECTED] writes:
In trying to come up with a test scenario, I loaded this db into a 7.4 db
and got a similar message. It shows up as follows:
ERROR: attempted to mark4update invisible tuple
CONTEXT: PL/pgSQL function c_delete_categories line 14 at SQL statement
Is
Wade Klaver [EMAIL PROTECTED] writes:
OK, I set you up a login on arch.wavefire.com
Okay, what I find is this sequence of events:
1. delete from te_users where id = 954;
2. The ON DELETE CASCADE RI constraint propagates this to a delete of
some row(s) in c_categories.
3. That fires the
On Wed, 24 Sep 2003, Tom Lane wrote:
Wade Klaver [EMAIL PROTECTED] writes:
OK, I set you up a login on arch.wavefire.com
Okay, what I find is this sequence of events:
1. delete from te_users where id = 954;
2. The ON DELETE CASCADE RI constraint propagates this to a delete of
some
Hello folks,
Stumbled across an odd problem while cleaning data out of a database. I am
getting these invalid tid errors. I tried the upgrade from 7.3.2 to 7.3.4.
I tried a dumpall/initdb/restore... nadda. Nothing really usefull is coming
from the logs either, even though logging is
Wade Klaver [EMAIL PROTECTED] writes:
Stumbled across an odd problem while cleaning data out of a database. I am
getting these invalid tid errors. I tried the upgrade from 7.3.2 to
7.3.4.
Hm. We fixed something with a similar symptom as of 7.3.3:
Hello,
Using Postgresql 7.3 (CVS REL7_3_STABLE today), I received the following
error:
dropsites= delete from cart_stores;
ERROR: heap_update: (am)invalid tid
This came from a database that was dumped from 7.2.1 using 7.2.1's pg_dump
and imported into 7.3. I was able to delete the rows
22 matches
Mail list logo
