Re: The case against multixact GUCs

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: The case against multixact GUCs
Дата
Msg-id 534EC7AC.5020505@agliodbs.com
обсуждение исходный текст
Ответ на The case against multixact GUCs  (Josh Berkus <josh@agliodbs.com>)
Ответы Re: The case against multixact GUCs  (Andres Freund <andres@2ndquadrant.com>)
Список pgsql-hackers
On 03/12/2014 09:45 AM, Heikki Linnakangas wrote:
> In hindsight, I think permanent multixids in their current form was a
> mistake. Before 9.3, the thing that made multixids special was that they
> could just be thrown away at a restart. They didn't need freezing. Now
> that they do, why not just use regular XIDs for them? We had to
> duplicate much of the wraparound and freezing logic for multixids that
> simply would not have been an issue if we had used regular XIDs instead.
> 
> We could've perhaps kept the old multixids for their original purpose,
> as transient xids that can be forgotten about after all the old
> snapshots are gone. But for the permanent ones, it would've been simpler
> if we handled them more like subxids; make them part of the same XID
> space as regular XIDs.
> 
> This is pretty hand-wavy of course, and it's too late now.

So, if we ripped out all the multixact stuff for 9.4, what would that
cost us?  I'm serious.  The multixact stuff has been broken since 9.3
was released, and it's *still* broken.  We can't give users any guidance
or tools on how to set multixact stuff, and autovacuum doesn't handle it
properly.

Seems like this was just a bad patch and we should rip it out.  What
features do we lose?

-- 
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Clock sweep not caching enough B-Tree leaf pages?
Следующее
От: Andres Freund
Дата:
Сообщение: Re: The case against multixact GUCs