On Fri, Jun 5, 2015 at 10:27 AM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
