On Wed, Sep 5, 2018 at 2:39 PM Alexander Korotkov
<a.korotkov@postgrespro.ru> wrote:
> On Wed, Sep 5, 2018 at 12:26 PM Alexander Korotkov
> <a.korotkov@postgrespro.ru> wrote:
> > On Wed, Sep 5, 2018 at 1:45 AM R, Siva <sivasubr@amazon.com> wrote:
> > > On Tue, Sep 4, 2018 at 09:16 PM, Alexander Korotkov <a.korotkov@postgrespro.ru> wrote:
> > > > Do you have a test scenario for reproduction of this issue? We need
> > > > it to ensure that fix is correct.
> > >
> > > Unfortunately, I do not have a way of reproducing this issue.
> > > So far I have tried a workload consisting of inserts (of the
> > > same attribute value that is indexed), batch deletes of rows
> > > and vacuum interleaved with engine crash/restarts.
> >
> > Issue reproduction and testing is essential for bug fix. Remember
> > last time you reported GIN bug [1], after issue reproduction it
> > appears that we have more things to fix. I's quite clear for me that
> > if segment list contains GIN_SEGMENT_INSERT before GIN_SEGMENT_DELETE,
> > then it might lead to wrong behavior in ginRedoRecompress(). But it's
> > not yet clear to understand what code patch could lead to such segment
> > list... I'll explore code more and probably will come with some idea.
>
> Aha, I've managed to reproduce this.
> 1. Apply ginRedoRecompress-asserts.patch, which add assertions to
> ginRedoRecompress() detecting past opaque writes.
It was wrong, sorry. It appears that I put strict inequality into
asserts, while there should be loose inequality. Correct version of
patch is attached. And scenario I've posted isn't really reproducing
the bug...
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company