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?
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 0Why 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
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, Pennsylvania 19026
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