Re: Bug in ginRedoRecompress that causes opaque data on page to be overrun

On Tue, Sep 5, 2018 at 08:55 PM, Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> wrote:
> Finally I managed to reproduce the bug. The scenario is following.
> Underlying idea is that when insertion of multiple tuples goes to the
> beginning of the page and this insertion succeed only thanks to
> collapse of some short segments together, then this insertion wouldn't
> fit to the page if given alone.

Sorry for the late reply.
Thank you so much for working on this and reproducing the issue!
Like you mentioned, the WAL record where we detected this problem
has future segments deleted due to compaction and written out
as an insert segment.

> alter index test_idx set (fastupdate = on);
Just curious why does this help with the repro? This is related to only
using the Gin pending list vs the posting tree.

I will try to reproduce the issue with the above workload and
also test the fix with the same and report back.

On Wed, Sep 5, 2018 at 5:24 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> Hmm, could you share the sequence of what kind of WAL has applied to
> the broken page? I suspect the segment list contains
> GIN_SEGMENT_REPLACE before GIN_SEGMENT_INSERT.

These are the segment operations on the WAL in sequence:
- 1 Replace action on segment N
- 5 Insert actions after segment N - the 5th insert action is essentially
replacing the last 3 remaining segments with a new one.
- 3 delete actions on the remaining segments.

Best
Siva