Re: all_visible replay aborting due to uninitialized pages
От | Andres Freund |
---|---|
Тема | Re: all_visible replay aborting due to uninitialized pages |
Дата | |
Msg-id | 20130530062931.GA4201@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: all_visible replay aborting due to uninitialized pages (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: all_visible replay aborting due to uninitialized pages
|
Список | pgsql-hackers |
On 2013-05-29 23:01:31 -0400, Robert Haas wrote: > On Wed, May 29, 2013 at 9:57 AM, Andres Freund <andres@2ndquadrant.com> wrote: > >> Thought about that, but given that 9.3's visibilitymap_set already will > >> already FPI heap pages I concluded it wouldn't really be an improvement > >> since it's only one ||log_heap_page or so there. Not sure what's > >> better. Will write the patch and see how it goes. > > > > Ended up using log_newpage_buffer since reusing visibilitymap_set's > > record would break the wal format as we currently do not accept an FPI > > on the heap pages during replay when < 9.3. Forcing to upgrade the > > client first would be rather unfriendly... > > > > That has the disadvantage of logging a full heap page since it doesn't > > use the hole optimization but this happens really infrequently, so ... > > Yeah, I think it's fine. The patch also looks fine, although I think > the comments could use a bit of tidying. I guess we need to > back-patch this all the way back to 8.4? It will require some > adjustments for the older branches. I think 9.2 is actually far enough and it should apply there. Before that we only logged the unsetting of all_visible via heap_(inset|update|delete)'s wal records not the setting as far as I can tell. So I don't immediately see a danger < 9.2. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: