Re: Multixid hindsight design

On Fri, Jun 5, 2015 at 10:27 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> That way if we need to make Offsets SLRU persistent it won't bloat.
>> We then leave the Members SLRU as non-persistent, just as it was <9.3
>
> I don't think you can do that, because it supposes that locking XIDs need
> not be remembered across a crash. Don't prepared transactions break that
> assumption?

Well, that issue existed before 9.3, too. It's possible our old
releases weren't entirely correct either, but the big change in 9.3 is
that we have to keep MultiXacts around until they are frozen, rather
than just until their member transactions are no longer running. If I
understand correctly, Simon's proposal would mean that
pg_multixact/offsets would still need to survive until freezing, but
pg_multixact/members would only need to survive until the member
transactions were no longer running. That might span a crash or
restart, in the case of prepared transactions, but we could clean up
the member offsets when the prepared transactions were committed,
rather than having to scan every table in the cluster first. That
only eliminates half the need for multixact vacuuming, but it's
something.

It would be a great deal nicer if we didn't have to keep ANY of the
transactional data for a tuple around once it's all-visible. Heikki
defined ephemeral as "only needed when xmin or xmax is in-progress",
but if we extended that definition slightly to "only needed when xmin
or xmax is in-progress or commited but not all-visible" then the
amount non-ephemeral data in the tuple header is 5 bytes (infomasks +
t_hoff).

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company