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
|
Список | 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 по дате отправления: