Re: PL/pgSQL bug?

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: PL/pgSQL bug?
Дата
Msg-id 3B820159.CE07AA2A@tm.ee
обсуждение исходный текст
Ответ на PL/pgSQL bug?  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Ответы Re: PL/pgSQL bug?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Tom Lane wrote:
> 
> Tatsuo Ishii <t-ishii@sra.co.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tatsuo Ishii
Дата:
Сообщение: Re: encoding: ODBC, createdb
Следующее
От: Bruce Momjian
Дата:
Сообщение: Link to bug webpage