Re: [HACKERS] Fix checkpoint skip logic on idle systems by trackingLSN progress
От | Amit Kapila |
---|---|
Тема | Re: [HACKERS] Fix checkpoint skip logic on idle systems by trackingLSN progress |
Дата | |
Msg-id | CAA4eK1K1Abk0zL=a9QJEvo-qTNtgVZM++cpBqS7m1gFX-+3BBg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fix checkpoint skip logic on idle systems by tracking LSN progress (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Список | pgsql-hackers |
On Thu, Dec 22, 2016 at 3:10 AM, Andres Freund <andres@anarazel.de> wrote: > On 2016-12-21 16:35:28 -0500, Robert Haas wrote: >> On Wed, Dec 21, 2016 at 4:28 PM, Andres Freund <andres@anarazel.de> wrote: >> > - Similarly I don't like the name "progress LSN" much. What does >> > "progress" really mean in that". Maybe "consistency LSN"? >> >> Whoa. -1 from me for "consistency LSN". Consistency has to with >> whether the cluster has recovered up to the minimum recovery point or >> whatever -- that is -- questions like "am i going to run into torn >> pages?" and "should I expect some heap tuples to maybe be missing >> index tuples, or the other way around?". > > That's imo pretty much what progress LSN currently describes. Have there > been any records which are important for durability/consistency and > hence need to be archived and such. > > >> What I think "progress LSN" >> is getting at -- actually fairly well -- is whether we're getting >> anything *important* done, not whether we are consistent. I don't >> mind changing the name, but not to consistency LSN. > > Well, progress could just as well be replay. Or the actual insertion > point. Or up to where we've written out. Or synced out. Or > replicated.... > > Open to other suggestions - I'm not really happy with consistency LSN, > but definitely unhappy with progress LSN. > last_essential_LSN? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: