Re: Further open item (Was: Status of 7.2)

From: Hannu Krosing <hannu(at)tm(dot)ee>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: "Tille, Andreas" <TilleA(at)rki(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: Further open item (Was: Status of 7.2)
Date: 2001-11-22 08:59:50
Message-ID: 3BFCBE86.30FD79B2@tm.ee
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:
>
> Huh, a non-zero XMAX is fine. You mark the XMAX when you _think_ you
> are updating it. It is only expired when the XMAX on the tuple is
> committed.

But

http://www.postgresql.org/idocs/index.php?sql-syntax-columns.html

claims:

xmax The identity (transaction ID) of the deleting transaction,
or zero for an undeleted tuple. In practice, this is
never nonzero for a visible tuple.

cmax The command identifier within the deleting transaction,
or zero. Again, this is never nonzero for a visible tuple.

Which is IMHO good and useful behaviour, for example for all kinds of
mirroring

I also think that this kas historically been the behaviour and that
this was broken sometime in not too distant past (i.e after postgres95
;)
by foreign keys and/or somesuch.

Tom Lane once told me about a way to determine the visibility of a tuple
by other means than [x|c][min|max] but I can't find/remember it anymore
;(

-----------------
Hannu

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message sugita 2001-11-22 09:00:52 Re: Rejection of the smallest int8
Previous Message Mariusz Czułada 2001-11-22 07:22:57 Taking databases offline