(more fruit from my little page-image-comparison hack)
WAL replay of filling a GIN fast list page is a bit funky. I believe there are two bugs in it, but they're both harmless:
writeListPage function initializes the page, and adds a bunch of tuples to it. All the tuples are included in the WAL record, and marked as belonging to the buffer. So far so good. But since the page is re-initialized from scratch, its LSN is always 0, so XLogInsert will always create a full-page-image of it. That's harmless, but usually we don't do a full-page image when we have all the information to re-create the page from scratch anyway. It does cause some unnecessary bloating of the WAL, because the information to recreate the page from scratch takes less space than the full page image.
The second bug is in the redo routine of that, ginRedoInsertListPage. The loop that inserts all the tuples to the page is missing an "off++", so it inserts all the tuples to offset 1. So the tuples end up on the page in reverse order. Not just reverse physical order, like in the B-tree split code, but reverse itemno order. That happens to work because the order of the tuples doesn't matter to scans, and we also never remove individual tuples from fast list pages. You only see this happening if you run with full_page_images=off, because of the first bug.
Although these are harmless, the second bug in particular is a bit scary. I think we should fix and backpatch these.
- Heikki -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
