On Wed, Sep 5, 2018 at 2:39 PM Alexander Korotkov <a.korot...@postgrespro.ru> wrote: > On Wed, Sep 5, 2018 at 12:26 PM Alexander Korotkov > <a.korot...@postgrespro.ru> wrote: > > On Wed, Sep 5, 2018 at 1:45 AM R, Siva <sivas...@amazon.com> wrote: > > > On Tue, Sep 4, 2018 at 09:16 PM, Alexander Korotkov > > > <a.korot...@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
ginRedoRecompress-asserts-v2.patch
Description: Binary data
