On Thu, Jun 19, 2014 at 09:06:54PM -0400, Alvaro Herrera wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian wrote:
>
> > Bruce Momjian wrote:
> >
> > > > 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, what would a legitimate 0000 file at wrap-around time look like?
> > > Would there have to be an 'ffff' or 'ffffff' file?
> >
> > Since I was wrong, there is no point in further research here. Anyway
> > the last file before wrapping around in pg_multixact/members is FFFF.
>
> Oops, I meant the last file before wrap in pg_multixact/offsets is FFFF,
> which is what we're talking about in this thread.
>
> For members it's 14078, but it's not relevant here.
OK, so the next questions is, what will the minor-release-note query we
give users to test this look like? Do we expect no gaps in numbering?
Is it enough to test for the existance of '0000' and lack of '0001' and
'FFFF'? Basically, if we expect no gaps in normal numbering, then a
'0000' with no number after it and no wrap-around number before it means
the '0000' is left over from initdb and can be removed.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ Everyone has their own god. +
