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:

Reply via email to