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?
|
| Список | 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 по дате отправления: