On Wed, Jun 18, 2014 at 06:51:31PM -0400, Alvaro Herrera wrote:
> > This is a bug in 9.3 pg_upgrade as well? Why has no one reported it
> > before?
>
> I think one reason is that not all upgrades see an issue here; for old
> clusters that haven't gone beyond the 0000 offset file, there is no
> problem. For clusters that have gone beyond 0000 but not by much, the
> file will be deleted during the first truncation. It only becomes a
> problem if the cluster is close enough to 2^31. Another thing to keep
> in consideration is that initdb initializes all databases' datminmxid to
> 1. If the old cluster was past the 2^31 point, it means the datminmxid
> doesn't move from 1 until the actual wraparound.
OK, so the xid has to be beyond 2^31 during pg_upgrade to trigger a
problem? That might explain the rare reporting of this bug. What would
the test query look like so we can tell people when to remove the '0000'
files? Would we need to see the existence of '0000' and high-numbered
files? How high? What does a 2^31 file look like?
Also, is there a reason you didn't remove the 'members/0000' file in your
patch? I have removed it in my version.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +