From: | Hannu Krosing <hannu(at)tm(dot)ee> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org, Jan Wieck <JanWieck(at)Yahoo(dot)com> |
Subject: | Re: PL/pgSQL bug? |
Date: | 2001-08-21 06:36:09 |
Message-ID: | 3B820159.CE07AA2A@tm.ee |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
>
> Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> writes:
> > NOTICE: ctid (0,5) xmin 645188 xmax 645190 cmin 2 cmax 2
> > This is odd too, since xmax > 0 or cmax > 0 should never happen with
> > visible tuples, in my understanding.
>
> That's what the docs presently say, but they're in error --- nonzero
> xmax could represent a not-yet-committed deleting xact (or one that
> did commit, but not in your snapshot); or it could be from a deleting
> xact that rolled back.
or it can come from referential integrity triggers:
hannu=# create table parent(parid integer primary key);
NOTICE: CREATE TABLE/PRIMARY KEY will create implicit index
'parent_pkey' for table 'parent'
CREATE
hannu=# create table child(cldid integer references parent on update
cascade);
NOTICE: CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
check(s)
CREATE
hannu=# insert into parent values(1);
INSERT 20652 1
hannu=# insert into child values(1);
INSERT 20653 1
hannu=# update parent set parid=2;
UPDATE 1
hannu=# select xmin,xmax,cmin,cmax,parid from parent;
xmin | xmax | cmin | cmax | parid
------+------+------+------+-------
731 | 731 | 0 | 4 | 2
(1 row)
Now I have a question: if xmax is not used in determining tuple
visibility
(as I had assumed earlier) then what is ? How does postgres decide that
a
tuple is deleted ?
--------------------
Hannu
From | Date | Subject | |
---|---|---|---|
Next Message | Karel Zak | 2001-08-21 07:28:39 | Re: encoding: ODBC, createdb |
Previous Message | Lincoln Yeoh | 2001-08-21 06:26:06 | RE: User locks code |