From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Bruce Momjian <bruce@momjian.us>
Cc: Andres Freund <andres@2ndquadrant.com>
Cc: PostgreSQL Bugs <pgsql-bugs@postgresql.org>
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
Date: Fri, 27 Jun 2014 17:05:21 -0400
Message-ID: <20140627210520.GP7340@eldon.alvh.no-ip.org> (raw)
In-Reply-To: <20140624201346.GB17110@momjian.us>
References: <20140619020633.GA20469@momjian.us>
<20140619015205.GD3806@momjian.us>
<20140619014034.GC3806@momjian.us>
<20140619220425.GQ18688@eldon.alvh.no-ip.org>
<20140620010653.GS18688@eldon.alvh.no-ip.org>
<20140620180725.GD29143@momjian.us>
<20140624201346.GB17110@momjian.us>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-bugs>
Bruce Momjian wrote:
> Assuming this is true, here is a query we can put in the next 9.3 minor
> release notes to tell users if they need to remove the '0000' file:
>
> WITH list(file) AS
> (
> SELECT * FROM pg_ls_dir('pg_multixact/offsets')
> )
> SELECT EXISTS (SELECT * FROM list WHERE file = '0000') AND
> NOT EXISTS (SELECT * FROM list WHERE file = '0001') AND
> NOT EXISTS (SELECT * FROM list WHERE file = 'FFFF') AND
> EXISTS (SELECT * FROM list WHERE file != '0000')
> AS file_removal_needed;
>
> Do they need to remove the members/0000 file too?
No, the members file shouldn't be removed; if they have used multixacts
at all since upgrading, the members/0000 file contains the members of
the first bunch of multis. Removing it would remove valid data. (Also
I still think that removing the members/0000 file that initdb creates is
a mistake.)
I think the query above is correct. One possible quibble is a FFFF
segment that isn't allocated in full. I don't think this is a problem,
because although the 0000 file would survive deletion, it would be
overwritten with zeroes as soon as the counter wraps around. Since 0000
is seen as "in the future" as soon as file 8000 starts being used, it
shouldn't be a problem there.
Another thing probably worth doing is have pg_upgrade set
pg_database.datminmxid to the minimum of pg_class.relminmxid on each
database. Right now these values are all initialized to 1, which is a
problem. We have set_frozenxids() which appears to be related, although
I don't readily understand what that is doing.
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: alvherre@2ndquadrant.com, bruce@momjian.us, andres@2ndquadrant.com
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
In-Reply-To: <20140627210520.GP7340@eldon.alvh.no-ip.org>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox