Re: The case against multixact GUCs

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: The case against multixact GUCs
Дата
Msg-id 53208F1E.8030100@vmware.com
обсуждение исходный текст
Ответ на Re: The case against multixact GUCs  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: The case against multixact GUCs  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 03/12/2014 06:26 PM, Robert Haas wrote:
> On Tue, Mar 11, 2014 at 3:14 PM, Josh Berkus <josh@agliodbs.com> wrote:
>> In the 9.3.3 updates, we added three new GUCs to control multixact
>> freezing.  This was an unprecented move in my memory -- I can't recall
>> ever adding a GUC to a minor release which wasn't backwards
>> compatibility for a security fix.  This was a mistake.
>
> I disagree.  I think it was the right decision.  I think it was a
> mistake not including all of that stuff in the first place, and I
> think it's good that we've now corrected that oversight.

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.

- Heikki



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

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: pgstat wait timeout (RE: contrib/cache_scan)
Следующее
От: Tom Lane
Дата:
Сообщение: Re: pgstat wait timeout (RE: contrib/cache_scan)