Why both

    int           pid;
    TransactionId xid;

are used in XIDTAG?

lock.c:
 *                                      normal lock     user lock
 *
 *      lockmethod                      1               2
 *      tag.relId                       rel oid         0
                                        ^^^^^^^^^^^^^^^^^
Due to this, user-lock LOCKTAG is always different from
normal-lock tag and so XIDTAG.lock is different also.

 *      tag.ItemPointerData.ip_blkid    block id        lock id2
 *      tag.ItemPointerData.ip_posid    tuple offset    lock id1
 *      xid.pid                         0               backend pid
 *      xid.xid                         xid or 0        0

Why not get rid of XIDTAG.xid and use XIDTAG.pid equal
to backend pid for both lock methods?

Comments?

Vadim

Tue, 04 May 1999 00:18:00 +0800
Vadim Mikheev <vadim@krs.ru>
XIDTAG ???
> Why both
> 
>     int           pid;
>     TransactionId xid;
> 
> are used in XIDTAG?
> 
> lock.c:
>  *                                      normal lock     user lock
>  *
>  *      lockmethod                      1               2
>  *      tag.relId                       rel oid         0
>                                         ^^^^^^^^^^^^^^^^^
> Due to this, user-lock LOCKTAG is always different from
> normal-lock tag and so XIDTAG.lock is different also.
> 
>  *      tag.ItemPointerData.ip_blkid    block id        lock id2
>  *      tag.ItemPointerData.ip_posid    tuple offset    lock id1
>  *      xid.pid                         0               backend pid
>  *      xid.xid                         xid or 0        0
> 
> Why not get rid of XIDTAG.xid and use XIDTAG.pid equal
> to backend pid for both lock methods?

Probably no reason for the transaction id.  I don't remember that being
used at all.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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

Mon, 3 May 1999 12:27:28 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] XIDTAG ???
On Mon, 3 May 1999, Bruce Momjian wrote:

> Probably no reason for the transaction id.  I don't remember that being
> used at all.

Do you mean that there is no reason for the xid to exist, as it is not
used?  If so, then may I humbly request that it be left in for another
six months in the hopes of using a transaction processing monitor to
distribute postgres across multiple machines safely?  I'll need the xid
if and when I start that project, which will be after I finish the
TPM.  8^)

--
Todd Graham Lewis                        Postmaster, MindSpring Enterprises
tlewis@mindspring.net                                (800) 719-4664, x22804

"A pint of sweat will save a gallon of blood."          -- George S. Patton


Mon, 3 May 1999 22:32:49 -0400 (EDT)
Todd Graham Lewis <tlewis@mindspring.net>
Re: [HACKERS] XIDTAG ???
> On Mon, 3 May 1999, Bruce Momjian wrote:
> 
> > Probably no reason for the transaction id.  I don't remember that being
> > used at all.
> 
> Do you mean that there is no reason for the xid to exist, as it is not
> used?  If so, then may I humbly request that it be left in for another
> six months in the hopes of using a transaction processing monitor to
> distribute postgres across multiple machines safely?  I'll need the xid
> if and when I start that project, which will be after I finish the
> TPM.  8^)

No, I don't recommend removing it, but just not storing it in the lock
system.  There is no need for it there.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@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, 4 May 1999 00:41:30 -0400 (EDT)
Bruce Momjian <maillist@candle.pha.pa.us>
Re: [HACKERS] XIDTAG ???
> 
> > On Mon, 3 May 1999, Bruce Momjian wrote:
> > 
> > > Probably no reason for the transaction id.  I don't remember that being
> > > used at all.
> > 
> > Do you mean that there is no reason for the xid to exist, as it is not
> > used?  If so, then may I humbly request that it be left in for another
> > six months in the hopes of using a transaction processing monitor to
> > distribute postgres across multiple machines safely?  I'll need the xid
> > if and when I start that project, which will be after I finish the
> > TPM.  8^)
> 
> No, I don't recommend removing it, but just not storing it in the lock
> system.  There is no need for it there.

I don't see any urgent reason for removing it. For the moment I would leave
the code as is. A distributed postgres sounds interesting.

-- 
Massimo Dal Zotto

+----------------------------------------------------------------------+
|  Massimo Dal Zotto               email: dz@cs.unitn.it               |
|  Via Marconi, 141                phone: ++39-0461534251              |
|  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
|  Italy                             pgp: finger dz@tango.cs.unitn.it  |
+----------------------------------------------------------------------+

Tue, 4 May 1999 09:31:35 +0200 (MET DST)
Massimo Dal Zotto <dz@cs.unitn.it>
Re: [HACKERS] XIDTAG ???
Massimo Dal Zotto ha scritto:

> >
> > > On Mon, 3 May 1999, Bruce Momjian wrote:
> > >
> > > > Probably no reason for the transaction id.  I don't remember that being
> > > > used at all.
> > >
> > > Do you mean that there is no reason for the xid to exist, as it is not
> > > used?  If so, then may I humbly request that it be left in for another

If I understand you are talking about to take off the xid type, if so,
I want warn you that xmin is an xid type and we are using it as
a versioning-row on psqlodbc.

> > > six months in the hopes of using a transaction processing monitor to
> > > distribute postgres across multiple machines safely?  I'll need the xid
> > > if and when I start that project, which will be after I finish the
> > > TPM.  8^)
> >
> > No, I don't recommend removing it, but just not storing it in the lock
> > system.  There is no need for it there.
>
> I don't see any urgent reason for removing it. For the moment I would leave
> the code as is. A distributed postgres sounds interesting.
>
> --
> Massimo Dal Zotto
>
> +----------------------------------------------------------------------+
> |  Massimo Dal Zotto               email: dz@cs.unitn.it               |
> |  Via Marconi, 141                phone: ++39-0461534251              |
> |  38057 Pergine Valsugana (TN)      www: http://www.cs.unitn.it/~dz/  |
> |  Italy                             pgp: finger dz@tango.cs.unitn.it  |
> +----------------------------------------------------------------------+

> ______________________________________________________________

PostgreSQL 6.5.0 on i586-pc-linux-gnu, compiled by gcc 2.7.2.3
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Jose'



Tue, 04 May 1999 14:05:39 +0200
=?iso-8859-1?Q?Jos=E9?= Soares <jose@sferacarta.com>
Re: [HACKERS] XIDTAG ???
On Tue, 4 May 1999, Bruce Momjian wrote:

> No, I don't recommend removing it, but just not storing it in the lock
> system.  There is no need for it there.

Ahh, sorry I misinterpreted you.  Carry on!

--
Todd Graham Lewis                        Postmaster, MindSpring Enterprises
tlewis@mindspring.net                                (800) 719-4664, x22804

"A pint of sweat will save a gallon of blood."          -- George S. Patton


Tue, 4 May 1999 10:53:39 -0400 (EDT)
Todd Graham Lewis <tlewis@mindspring.net>
Re: [HACKERS] XIDTAG ???