Re: The case against multixact GUCs

From: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: The case against multixact GUCs
Date: 2014-03-12 16:45:18
Message-ID: 53208F1E.8030100@vmware.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 03/12/2014 06:26 PM, Robert Haas wrote:
> On Tue, Mar 11, 2014 at 3:14 PM, Josh Berkus <josh(at)agliodbs(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-03-12 16:51:45 Re: pgstat wait timeout (RE: contrib/cache_scan)
Previous Message Jeff Janes 2014-03-12 16:42:23 Re: pgstat wait timeout (RE: contrib/cache_scan)