Re: beta1 & beta2 & Windows & heavy load
От | Alvaro Herrera |
---|---|
Тема | Re: beta1 & beta2 & Windows & heavy load |
Дата | |
Msg-id | 20040913214834.GA5802@dcc.uchile.cl обсуждение исходный текст |
Ответ на | Re: beta1 & beta2 & Windows & heavy load (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: beta1 & beta2 & Windows & heavy load
|
Список | pgsql-hackers |
On Sun, Sep 12, 2004 at 08:28:42PM -0400, Tom Lane wrote: > 1. During CommitSubTransaction, release the lock on the subtransaction's > XID (but not any of its other locks). This means that the number of > locks held due to just transaction XIDs is no more than the subxact > nesting depth, rather than growing with the number of subcommitted XIDs. > > 2. XactLockTableWait would have to do something like this: > > for (;;) > { > wait for lock associated with xid; > if (!TransactionIdIsInProgress(xid)) > break; > xid = SubTransGetParent(xid); > } FWIW, this works for me. > The other question is whether it's worth some extra overhead in > XactLockTableWait to save on shared memory. I'm inclined to think it > is, mainly because you don't get into XactLockTableWait in the first > place unless you're going to have to block. Furthermore, the savings are possibly unbounded, so this is a good idea anyway. From the example case it's not hard to imagine situations where we will want lots of subtransactions; just using exceptions in functions will implicitly open new ones! (This kind of bothers me because of the possibly very fast use of Xids, accelerating Xid counter wraparound ...) -- Alvaro Herrera (<alvherre[a]dcc.uchile.cl>) "La principal característica humana es la tontería" (Augusto Monterroso)
В списке pgsql-hackers по дате отправления: