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
