Tom Lane wrote:
> No, the ShareLock is the means used when transaction A needs to wait for
> transaction B to complete --- it tries to take a share lock on xact B's
> XID, which of course is blocked as along as B is holding its
> ExclusiveLock. This is used when there is a row-update conflict, ie,
> A wants to lock or update a table row that B's already locked/updated.
> Unfortunately, in 7.4 there isn't any easy way to find out exactly which
> row transaction A is waiting on.
My function has a loop in it defined as:
FOR price_record IN select pd.price, sp.sku_id from sku_price as sp,
price_data as pd where sp.price_data_id = pd.price_data_id AND
pd.domain_id = LIVE LOOP
-- some selects and inserts
END LOOP;
Will postgres lock on all rows as it goes through this loop? Or can you
give me a better idea of what I can expect to be locked in my example?
Thanks a lot -
Mott