On Wed, Jul 17, 2019 at 3:53 AM Andres Freund <and...@anarazel.de> wrote: > > Hi, > > On 2019-07-15 12:26:21 -0400, Robert Haas wrote: > > Yeah. I didn't understand that explanation. It seems to me that one > > of the fundamental design questions for this system is whether we > > should allow there to be an unbounded number of transactions that are > > pending undo application, or whether it's OK to enforce a hard limit. > > Either way, there should certainly be pressure applied to try to keep > > the number low, like forcing undo application into the foreground when > > a backlog is accumulating, but the question is what to do when that's > > insufficient. My original idea was that we should not have a hard > > limit, in which case the shared memory data on what is pending might > > be incomplete, in which case we would need the discard workers to > > discover transactions needing undo and add them to the shared memory > > data structures, and if those structures are full, then we'd just skip > > adding those details and rediscover those transactions again at some > > future point. > > > > But, my understanding of the current design being implemented is that > > there is a hard limit on the number of transactions that can be > > pending undo and the in-memory data structures are sized accordingly. > > My understanding is that that's really just an outcome of needing to > maintain oldestXidHavingUndo accurately, right? >
Yes. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
