Re: Assertion failure when streaming logical changes - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Assertion failure when streaming logical changes
Date
Msg-id 20150210124608.GE21017@alap3.anarazel.de
Whole thread Raw
In response to Assertion failure when streaming logical changes  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Assertion failure when streaming logical changes  (Michael Paquier <michael.paquier@gmail.com>)
Re: Assertion failure when streaming logical changes  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: pg_basebackup may fail to send feedbacks.
Next
From: Michael Paquier
Date:
Subject: Re: Assertion failure when streaming logical changes