On Wed, 2009-01-07 at 15:43 +0200, Heikki Linnakangas wrote: > Another annoyance I noticed while testing
I'm sorry this has annoyed you. Thanks for testing. > the case of a lot of > subtransactions (overflowing the procarray cache) is that when you have > a transaction with a lot of subtransactions open, getting the initial > snapshot fails, ...on that attempt only, yes. > and the standby doesn't open for read-only queries. It will eventually do so, at the first time there is no overflow, so in most cases the wait will be fairly short. I thought it was code that would so seldom run that it was unlikely to be bug free. I would prefer to record this as a possible enhancement once committed rather than an essential fix; would you agree? > Normally, GetRunningTransactionData determines the xid of the latest > running xid by scanning the procarray. If the subxid cache has > overflowed, it simply gives up. Comment there suggests that it could > call ReadNewTransactionId() instead, like it does when there's no active > xids in proc array. I think we should do that, or something else to > alleviate the problem. I mention in comments that I was worried about the contention that would cause since this runs in all servers. > When there's no xids in the procarray, couldn't we just use > latestCompletedXid instead of calling ReadNewTransactionId()? latestCompletedXid is protected by ProcArrayLock so not much difference between those two. If you're saying you'd prefer latestCompletedXid then I can make that change. -- Simon Riggs www.2ndQuadrant.com PostgreSQL Training, Services and Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
