Thread

1. RE: Plans for solving the VACUUM problem

   Henshall, Stuart - WCP <shenshall@westcountrypublications.co.uk> — 2001-05-21T12:00:59Z

   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>
   
   
   

2. Re: RE: Plans for solving the VACUUM problem

   Hannu Krosing <hannu@tm.ee> — 2001-05-21T14:53:13Z

   "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
   
   

3. Re: RE: Plans for solving the VACUUM problem

   Bruce Momjian <pgman@candle.pha.pa.us> — 2001-05-22T04:38:15Z

   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
   
   

4. XMAX weirdness (was: Plans for solving the VACUUM problem)

   Hannu Krosing <hannu@tm.ee> — 2001-05-22T08:20:26Z

   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
   
   

5. Re: XMAX weirdness (was: Plans for solving the VACUUM problem)

   Tom Lane <tgl@sss.pgh.pa.us> — 2001-05-23T19:12:14Z

   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