Re: Assertion failure when streaming logical changes

Hi,

On 2015-02-10 21:20:37 +0900, Michael Paquier wrote:
> Using test_decoding on HEAD (cc761b1) I am seeing the following assertion
> failure:
> TRAP: FailedAssertion("!(!((&RegisteredSnapshots)->ph_root ==
> ((void*)0)))", File: "snapmgr.c", Line: 677)

Ick. I guess a revert of 94028691609f8e148bd4ce72c46163f018832a5b fixes
it?

> (lldb) bt
> * thread #1: tid = 0x0000, 0x00007fff8b246d46 libsystem_kernel.dylib`__kill
> + 10, stop reason = signal SIGSTOP
> * frame #0: 0x00007fff8b246d46 libsystem_kernel.dylib`__kill + 10
> frame #1: 0x00007fff8861bf83 libsystem_c.dylib`abort + 177
> frame #2: 0x000000010b556dd9
> postgres`ExceptionalCondition(conditionName=0x000000010b66ffcb,
> errorType=0x000000010b5c105d, fileName=0x000000010b66fe68, lineNumber=677)
> + 137 at assert.c:54
> frame #3: 0x000000010b5af952
> postgres`UnregisterSnapshotFromOwner(snapshot=0x00007faea38c22d8,
> owner=0x00007faea38a6838) + 146 at snapmgr.c:677
> frame #4: 0x000000010b5af8b2
> postgres`UnregisterSnapshot(snapshot=0x00007faea38c22d8) + 50 at
> snapmgr.c:663
> frame #5: 0x000000010b0166ce
> postgres`systable_endscan(sysscan=0x00007faea38cf090) + 110 at genam.c:504
> frame #6: 0x000000010b5474b8
> postgres`RelationBuildTupleDesc(relation=0x0000000114932e68) + 952 at
> relcache.c:568
> frame #7: 0x000000010b53e45c
> postgres`RelationBuildDesc(targetRelId=3455, insertIt='\x01') + 604 at
> relcache.c:1035
> frame #8: 0x000000010b53d564
> postgres`RelationIdGetRelation(relationId=3455) + 324 at relcache.c:1777
> frame #9: 0x000000010aff093c postgres`relation_open(relationId=3455,
> lockmode=1) + 108 at heapam.c:1047
> frame #10: 0x000000010b016ac9 postgres`index_open(relationId=3455,
> lockmode=1) + 25 at indexam.c:167
> frame #11: 0x000000010b01603d
> postgres`systable_beginscan(heapRelation=0x00000001149214d0, indexId=3455,
> indexOK='\x01', snapshot=0x0000000000000000, nkeys=2,
> key=0x00007fff54c6a990) + 93 at genam.c:334
> frame #12: 0x000000010b54a976

Yea, it really looks like the above commit is to "blame". The new xmin
tracking infrastructure doesn't know about the historical snapshot...

Greetings,

Andres Freund

--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services