Re: Reviewing freeze map code
От | Andres Freund |
---|---|
Тема | Re: Reviewing freeze map code |
Дата | |
Msg-id | 20160701192351.s6revshsn2ir4szq@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Reviewing freeze map code (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: Reviewing freeze map code
Re: Reviewing freeze map code |
Список | pgsql-hackers |
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. > The only > cost of that is that vacuum will come along and mark the page > all-visible again instead of skipping it, but that's probably not an > enormous expense in most cases. I think the main cost is not having the page marked as all-visible for index-only purposes. If it's an insert mostly table, it can be a long while till vacuum comes around. Andres
В списке pgsql-hackers по дате отправления: