Re: POC: Cleaning up orphaned files using undo logs
От | Amit Kapila |
---|---|
Тема | Re: POC: Cleaning up orphaned files using undo logs |
Дата | |
Msg-id | CAA4eK1+iBf7AYwmWMR-eiKpEQfic3Q-9Rh4LNUnbR3TJZ_3LGA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: POC: Cleaning up orphaned files using undo logs (Andres Freund <andres@anarazel.de>) |
Список | pgsql-hackers |
On Wed, Jul 17, 2019 at 3:53 AM Andres Freund <andres@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
В списке pgsql-hackers по дате отправления: