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.comPostgreSQL Training, Services and Support
