Thread: 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
lockid1* 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
> 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, Pennsylvania19026
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
> 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, Pennsylvania19026
> > > 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 | +----------------------------------------------------------------------+
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'
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