On 16.01.2012 21:52, Alvaro Herrera wrote:
Excerpts from Heikki Linnakangas's message of lun ene 16 16:17:42 -0300 2012:
On 15.01.2012 06:49, Alvaro Herrera wrote:
- pg_upgrade bits are missing.
I guess we'll need to rewrite pg_multixact contents in pg_upgrade. Is
the page format backwards-compatible?
It's not.
I haven't worked out what pg_upgrade needs to do, honestly. I think we
should just not copy old pg_multixact files when upgrading across this
patch.
Sorry, I meant whether the *data* page format is backwards-compatible?
the multixact page format clearly isn't.
I was initially thinking that pg_multixact should return the
empty set if requested members of a multi that preceded the freeze
point. That way, I thought, we would just never try to access a page
originated in the older version (assuming the freeze point is set to
"current" whenever pg_upgrade runs). However, as things currently
stand, accessing an old multi raises an error. So maybe we need a
scheme a bit more complex to handle this.
Hmm, could we create new multixact files filled with zeros, covering the
range that was valid in the old cluster?
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
