Apologises if I've missed something, but isn't that the same xmin that ODBC
uses for row versioning?
- Stuart

	<Snip>
> Currently, the XMIN/XMAX command counters are used only by the current
> transaction, and they are useless once the transaction finishes and take
> up 8 bytes on disk.
	<Snip>


Mon, 21 May 2001 13:00:59 +0100
"Henshall, Stuart - WCP" <SHenshall@westcountrypublications.co.uk>
RE: Plans for solving the VACUUM problem
"Henshall, Stuart - WCP" wrote:
> 
> Apologises if I've missed something, but isn't that the same xmin that ODBC
> uses for row versioning?
> - Stuart
> 
>         <Snip>
> > Currently, the XMIN/XMAX command counters are used only by the current
> > transaction, and they are useless once the transaction finishes and take
> > up 8 bytes on disk.
>         <Snip>

BTW, is there some place where I could read about exact semantics of
sytem fields ?

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

Mon, 21 May 2001 16:53:13 +0200
Hannu Krosing <hannu@tm.ee>
Re: RE: Plans for solving the VACUUM problem

You can read my Internals paper at the bottom of developers corner.

[ Charset ISO-8859-15 unsupported, converting... ]
> "Henshall, Stuart - WCP" wrote:
> > 
> > Apologises if I've missed something, but isn't that the same xmin that ODBC
> > uses for row versioning?
> > - Stuart
> > 
> >         <Snip>
> > > Currently, the XMIN/XMAX command counters are used only by the current
> > > transaction, and they are useless once the transaction finishes and take
> > > up 8 bytes on disk.
> >         <Snip>
> 
> BTW, is there some place where I could read about exact semantics of
> sytem fields ?
> 
> --------------------
> Hannu
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 2: you can get off all lists at once with the unregister command
>     (send "unregister YourEmailAddressHere" to majordomo@postgresql.org)
> 

-- 
  Bruce Momjian                        |  http://candle.pha.pa.us
  pgman@candle.pha.pa.us               |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Tue, 22 May 2001 00:38:15 -0400 (EDT)
Bruce Momjian <pgman@candle.pha.pa.us>
Re: RE: Plans for solving the VACUUM problem
Bruce Momjian wrote:
> 
> You can read my Internals paper at the bottom of developers corner.
> 

in answer to my question:

> > BTW, is there some place where I could read about exact semantics of
> > sytem fields ?

the only thing I found was on page 50 which claimed that

xmax - destruction transaction id

which is what I remembered, 

but then no xmax should ever be visible in a regular query :


hannu=# create table parent(pid int primary key);
NOTICE:  CREATE TABLE/PRIMARY KEY will create implicit index
'parent_pkey' for table 'parent'
CREATE
hannu=# create table child(cid int references parent(pid) on update
cascade);
NOTICE:  CREATE TABLE will create implicit trigger(s) for FOREIGN KEY
check(s)
CREATE
hannu=# insert into parent values(1);
INSERT 27525 1
hannu=# insert into child values(1);
INSERT 27526 1
hannu=# update parent set pid=2;
UPDATE 1
hannu=# select xmin,xmax,* from parent;
 xmin | xmax | pid 
------+------+-----
  688 |  688 |   2
(1 row)

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

Tue, 22 May 2001 10:20:26 +0200
Hannu Krosing <hannu@tm.ee>
XMAX weirdness (was: Plans for solving the VACUUM problem)
Hannu Krosing <hannu@tm.ee> writes:
> but then no xmax should ever be visible in a regular query :

Not so.  For example, if a transaction tried to delete a tuple, but is
either still open or rolled back, then other transactions would see its
XID in the tuple's xmax.  Also, SELECT FOR UPDATE uses xmax to record
the XID of the transaction that has the tuple locked --- that's the
case you are seeing, because of the SELECT FOR UPDATE done by the
foreign-key triggers on the table.

There is a claim in the current documentation that xmax is never nonzero
in a visible tuple, but that's incorrect ...

			regards, tom lane

Wed, 23 May 2001 15:12:14 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: XMAX weirdness (was: Plans for solving the VACUUM problem) 