Re: Reviewing freeze map code
От | Amit Kapila |
---|---|
Тема | Re: Reviewing freeze map code |
Дата | |
Msg-id | CAA4eK1LhODFDbtgTjopmecYDXiCaenSsfWaKz1HQTKHgVOtQDw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Reviewing freeze map code (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Reviewing freeze map code
|
Список | pgsql-hackers |
On Sat, Jul 2, 2016 at 12:53 AM, Andres Freund <andres@anarazel.de> wrote: > On 2016-07-01 15:18:39 -0400, Robert Haas wrote: >> On Fri, Jul 1, 2016 at 10:22 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote: >> > Ah, you're right, I misunderstood. >> > >> > Attached updated patch incorporating your comments. >> > I've changed it so that heap_xlog_lock clears vm flags if page is >> > marked all frozen. >> >> I believe that this should be separated into two patches, since there >> are two issues here: >> >> 1. Locking a tuple doesn't clear the all-frozen bit, but needs to do so. >> 2. heap_update releases the buffer content lock without logging the >> changes it has made. >> >> With respect to #1, there is no need to clear the all-visible bit, >> only the all-frozen bit. However, that's a bit tricky given that we >> removed PD_ALL_FROZEN. Should we think about putting that back again? > > I think it's fine to just do the vm lookup. > >> Should we just clear all-visible and call it good enough? > > Given that we need to do that in heap_lock_tuple, which entirely > preserves all-visible (but shouldn't preserve all-frozen), ISTM we > better find something that doesn't invalidate all-visible. > Sounds logical, considering that we have a way to set all-frozen and vacuum does that as well. So probably either we need to have a new API or add a new parameter to visibilitymap_clear() to indicate the same. If we want to go that route, isn't it better to have PD_ALL_FROZEN as well? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: