On Thu, Feb 1, 2018 at 1:00 AM, Pavan Deolasee <pavan.deolasee@gmail.com> wrote:
> IMHO we're missing a point here. When xl_prev is changed to a 2-byte value
> (as the patch suggests), the risk only comes when an old WAL file is
> recycled for some future WAL file and the old and the future WAL file's
> segment numbers share the same low order 16-bits. Now as the patch stands,
> we take precaution to never reuse a WAL file with conflicting low order
> bits.
You and Simon seem to be assuming that the only case we need to worry
about is when the old segment had an xl_prev value at the same offset,
and you may be right, but if that is guaranteed, I don't understand
why it's guaranteed. Why couldn't that offset in the old WAL file
been in the middle of a WAL record and thus subject to containing any
random garbage?
If we know that, at the same offset in the previous WAL file, there
was definitely an xl_prev pointer, then it seems like some trick like
what you're proposing might work, although I'm not sure of the
details. But if that could've been something else -- like the middle
of a WAL record -- then that doesn't really help. Our chance of a
false match is pretty much just 2^-nbits.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company