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
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
