Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Tue, 30 Sep 2003, Tom Lane wrote:
>> ... Note that this implementation
>> means that case 3 will not throw errors, because such rows will be
>> ignored by the scan. I think this is an okay tradeoff for getting the
>> other cases right.
> It's probab
On Tue, 30 Sep 2003, Tom Lane wrote:
> Stephan Szabo <[EMAIL PROTECTED]> writes:
> > On Tue, 30 Sep 2003, Tom Lane wrote:
> >> ... Note that this implementation
> >> means that case 3 will not throw errors, because such rows will be
> >> ignored by the scan. I think this is an okay tradeoff for
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 handl
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 think the ones in the main functions n
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
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 o
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
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
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
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 eith
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
On Fri, 26 Sep 2003, Kevin Brown wrote:
> 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 pro
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 i
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 fa
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:
> >> 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 sa
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) an
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
>
>> 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 sen
Hello,
Naturally, as I found this problem in a production database running 7.3.4, a
back-patch to 7.3 would be desireable. Even if just a patch was available
and was not commited to -STABLE, this would do. I would also then be able to
test such a critter on our development server for a futur
I said:
> 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...)
I've committed the attached patch into CVS HEAD. I am now wondering
whet
Stephan Szabo <[EMAIL PROTECTED]> writes:
> On Wed, 24 Sep 2003, Tom Lane wrote:
>> But I'm wondering why we have to do this at all.)
> I think if you have something like:
> create table test1 (id int primary key, otherid int references test1);
> insert into test1 values (4,4);
> T1: begin;
> T1:
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
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 c
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 stateme
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 "c
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:
http://archives.postgresql.org/pgsql-
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 crank
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 indiv
29 matches
Mail list logo
