On Fri, Jan 12, 2018 at 10:49 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Claudio Freire <klaussfreire@gmail.com> writes: > On Sat, Dec 30, 2017 at 7:32 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> So we can't completely remove xl_prev field, without giving up some >> functionality.
> Or, you can use the lower 16-bits of the previous record's CRC
Hmm ... that is an interesting idea, but I'm not sure it helps much towards Simon's actual objective. AIUI the core problem here is the contention involved in retrieving the previous WAL record's address. Changing things so that we need the previous record's CRC isn't really gonna improve that --- if anything, it'll be worse, because the record's address can (in principle) be known sooner than its CRC.
Still, if we were just looking to shave some bits off of WAL record headers, it might be possible to do something with this idea.
regards, tom lane
I later realized. That's why I corrected myself to the first record, not the previous.
Now, that assumes there's enough entropy in CRC values to actually make good use of those 16 bits... there may not. WAL segments are highly compressible after all.
So, maybe a hash of the LSN of the first record instead? That should be guaranteed to have good entropy (given a good hash).
In any case, there are many rather good alternatives to the segment number that should be reasonably safe from consistent collisions with garbage data.
