On Thu, Sep 6, 2018 at 12:53 AM R, Siva <sivas...@amazon.com> wrote: > On Tue, Sep 5, 2018 at 08:55 PM, Alexander Korotkov > <a.korot...@postgrespro.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.
With (fastupdate = on) GIN performs bulk update of posting lists,
inserting multiple tuples at once if possible. With (fastupdate =
off) GIN always inserts tuples one-by-one. It might be still possible
to reproduce the issue with (fastupdate = off), but it seems even
harder.
BTW, I've tried the patch you've posted. On my test case it fails
with following assertion.
TRAP: FailedAssertion("!(a_action == 2)", File: "ginxlog.c", Line: 243)
I thought about fixing this issue more, and I decided we can fix it in
less invasive way. Once modification is started we can copy tail of
the page into separately allocated chunk of memory, and the use it as
the source of original segments. See the patch attached.
------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
ginRedoRecompress-tail-copy-v1.patch
Description: Binary data
