Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Andres Freund <andres(at)2ndquadrant(dot)com>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
Date: 2014-06-19 22:12:41
Message-ID: 20140619221240.GC27747@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

BTW I hacked up pg_resetxlog a bit to make it generate the necessary
pg_multixact/offset file when -m is given. This is not acceptable for
commit because it duplicates the #defines from pg_multixact.c, but maybe
we want this functionality enough that we're interested in a more
complete version of this patch; also it unconditionally writes one zero
byte to the file, which is of course wrong if the file exists and
already contains data.

It'd be nice to be able to write this in a way that lets it work for all
existing SLRU users (pg_clog is the most common, but
pg_multixact/members and the predicate locking stuff might also be
useful). Not sure what would that look like.

Another consideration is that it doesn't remove existing files that are
outside of the new valid range according to freezing parameters and
such, but I'm not sure this is really doable considering that we might
need to change the relminmxid and datminmxid values, etc.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
resetxlog_multi.patch text/x-diff 1.9 KB

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Andres Freund 2014-06-19 23:30:59 Re: BUG #10533: 9.4 beta1 assertion failure in autovacuum process
Previous Message Alvaro Herrera 2014-06-19 22:04:25 Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts