Re: [PATCHES] LockObject patch
Alvaro Herrera <[EMAIL PROTECTED]> writes: > On Mon, Dec 20, 2004 at 03:09:31PM -0500, Tom Lane wrote: >> I wonder whether it wouldn't be possible to clean up the "XactLockTable" >> kluge with this --- ie, instead of denoting transaction locks by a >> special relation ID, denote them by a special class ID. That might just >> move the kluginess from one place to another, but it's worth thinking about. > How about locking the special class InvalidOid? We don't use that ATM > AFAICS. No, that's not an improvement --- if the solution doesn't allow multiple classes of objects then we've not made any step forward. We probably ought to step back and think about what objects we need to be able to lock and what the identifying values are for each kind of object. Offhand I think we have: Whole relations: DBID, REL OID (with special case DBID=0 for shared rels) Pages within rels: DBID, REL OID, BLOCKNUM (same special case) Individual tuples (assuming we go the lockmanager route for this): DBID, REL OID, BLOCKNUM, OFFNUM (same special case) Transactions: XID (would sub-XID be of any use??) Non-relation objects: DBID, CLASS OID, OBJECT OID, OBJECT SUBID (it's reasonable to use DBID=0 for shared objects, eg users) (we could possibly dispense with subid but for now let's assume the same representation as in pg_depend and pg_description) Userlocks: DBID, ID1, ID2 (current implementation limits ID1 to 16 bits, but we could widen that if we wanted) Basically I think what we've got to decide is how to overlay these fields and how to tell the six cases apart. Since subids and offnums are only 16 bits, we could pack all of these cases into 64 bits with a 16-bit type identifier to distinguish the cases. That would mean that LOCKTAG doesn't get any bigger than it is now, and we'd have plenty of room for expansion still with more types. regards, tom lane ---(end of broadcast)--- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] LockObject patch
On Mon, Dec 20, 2004 at 03:52:57PM -0500, Bruce Momjian wrote: > When we roll over OID's do we make sure we never return InvalidOid? Yes. From GetNewObjectId() /* * Check for wraparound of the OID counter. We *must* not return 0 * (InvalidOid); and as long as we have to check that, it seems a good * idea to skip over everything below BootstrapObjectIdData too. (This * basically just reduces the odds of OID collision right after a wrap * occurs.) Note we are relying on unsigned comparison here. */ -- Alvaro Herrera (<[EMAIL PROTECTED]>) "Es filósofo el que disfruta con los enigmas" (G. Coli) ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] LockObject patch
Alvaro Herrera wrote: > On Mon, Dec 20, 2004 at 03:09:31PM -0500, Tom Lane wrote: > > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > > Here is the LockObject patch I was able to come up with. It's almost > > > the same patch that Rod Taylor published two years ago; basically, it > > > expands LOCKTAG with a ClassId attribute, and provides a LockObject > > > method to allow locking arbitrary objects. > > > > I wonder whether it wouldn't be possible to clean up the "XactLockTable" > > kluge with this --- ie, instead of denoting transaction locks by a > > special relation ID, denote them by a special class ID. That might just > > move the kluginess from one place to another, but it's worth thinking about. > > How about locking the special class InvalidOid? We don't use that ATM > AFAICS. When we roll over OID's do we make sure we never return InvalidOid? -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 8: explain analyze is your friend
Re: [PATCHES] LockObject patch
On Mon, Dec 20, 2004 at 03:09:31PM -0500, Tom Lane wrote: > Alvaro Herrera <[EMAIL PROTECTED]> writes: > > Here is the LockObject patch I was able to come up with. It's almost > > the same patch that Rod Taylor published two years ago; basically, it > > expands LOCKTAG with a ClassId attribute, and provides a LockObject > > method to allow locking arbitrary objects. > > I wonder whether it wouldn't be possible to clean up the "XactLockTable" > kluge with this --- ie, instead of denoting transaction locks by a > special relation ID, denote them by a special class ID. That might just > move the kluginess from one place to another, but it's worth thinking about. How about locking the special class InvalidOid? We don't use that ATM AFAICS. Anything else would require having a special relation registered, which is where we are now ... -- Alvaro Herrera (<[EMAIL PROTECTED]>) "La rebeldía es la virtud original del hombre" (Arthur Schopenhauer) ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] LockObject patch
Alvaro Herrera <[EMAIL PROTECTED]> writes: > Here is the LockObject patch I was able to come up with. It's almost > the same patch that Rod Taylor published two years ago; basically, it > expands LOCKTAG with a ClassId attribute, and provides a LockObject > method to allow locking arbitrary objects. I wonder whether it wouldn't be possible to clean up the "XactLockTable" kluge with this --- ie, instead of denoting transaction locks by a special relation ID, denote them by a special class ID. That might just move the kluginess from one place to another, but it's worth thinking about. regards, tom lane ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [PATCHES] LockObject patch
Alvaro Herrera <[EMAIL PROTECTED]> writes: > I just noticed that this uses the current database Id in the LOCKTAG ... > I think I'll just make it use InvalidOid, as we will only use it to lock > shared objects by now. It can be changed when (and if) we need > different semantics in the future. In that case call it LockSharedObject, or something like that. regards, tom lane ---(end of broadcast)--- TIP 7: don't forget to increase your free space map settings
Re: [PATCHES] LockObject patch
On Sun, Dec 19, 2004 at 11:40:40PM -0300, Alvaro Herrera wrote: Hackers, > Here is the LockObject patch I was able to come up with. It's almost > the same patch that Rod Taylor published two years ago; basically, it > expands LOCKTAG with a ClassId attribute, and provides a LockObject > method to allow locking arbitrary objects. I omitted the uses of the > new functionality. I just noticed that this uses the current database Id in the LOCKTAG ... I think I'll just make it use InvalidOid, as we will only use it to lock shared objects by now. It can be changed when (and if) we need different semantics in the future. -- Alvaro Herrera (<[EMAIL PROTECTED]>) Tulio: oh, para qué servirá este boton, Juan Carlos? Policarpo: No, aléjense, no toquen la consola! Juan Carlos: Lo apretaré una y otra vez. ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
