On 09 April 2014 21:25, Robert Haas Wrote: > >> > Deadlock Detection: > >> I'm not sure how this would work out internally > > In order to resolve deadlock, two member variable will be created in > the structure PROLOCK: > > Bitmask for lock types currently held by autonomous > transaction. > > LOCKMASK holdMaskByAutoTx[MAX_AUTO_TX_LEVEL] > > Bitmask for lock types currently held by main transaction. > > LOCKMASK holdMaskByNormalTx > > > > Now when we grant the lock to particular transaction, depending on > > type of transaction, bit Mask will be set for either holdMaskByAutoTx > or holdMaskByNormalTx. > > Similar when lock is ungranted, corresponding bitmask will be reset. > > That sounds pretty ugly, not to mention the fact that it will cause a > substantial increase in the amount of memory required to store > PROCLOCKs. It will probably slow things down, too.
Actually I followed above design to keep it align with the existing design. As I understand, currently also all lock conflict is checked based on the corresponding lock bit mask. This is good catch that shared memory required will increase but isn't it justified from user perspective since we are allowing more transactions per session and hence memory required to store various kind of resources will increase. Since we are just additionally setting the bitmask for each lock (in-case there is autonomous transaction, then there will be one more additional bit mask setting and deadlock check), I don't think it should slow down the overall operation. Also We can keep number of autonomous transaction configurable(default-0), to keep it less impacting incase it is not configured. An autonomous transaction can also conflict with main transaction, so in order to check conflict between them, I am distinguishing at this level. Please correct me If I am wrong anywhere and also please provide your thought on this and on overall design. Thanks and Regards, Kumar Rajeev Rastogi -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
