Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts - Mailing list pgsql-bugs

From Alvaro Herrera
Subject Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
Date
Msg-id 20140627211558.GQ7340@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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

pgsql-bugs by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: pg_upgrade < 9.3 -> >=9.3 misses a step around multixacts
Next
From: kai@schwebke.com
Date:
Subject: BUG #10793: Empty result set instead of column does not exist error using CTE.