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-27 21:15:58
Message-ID: 20140627211558.GQ7340@eldon.alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Alvaro Herrera wrote:

> 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.

... that said, there is a wraparound check in SimpleLruTruncate: if you
are using file 8000 and above, slru.c refuses to remove the old files
because it believes you may have already suffered wraparound, and you
would get a WARNING message every time the truncation was attempted.

The warnings would probably be pretty much invisible because of their
low frequency. This might be improved by my commit this afternoon,
which should cause multixact truncations to be attempted much more
often. In any case, just removing the offending offsets/0000 file
should clear it up.

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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message kai 2014-06-28 06:41:57 BUG #10793: Empty result set instead of column does not exist error using CTE.
Previous Message Alvaro Herrera 2014-06-27 21:05:21 Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts