On 08/15/2014 09:42 AM, Andres Freund wrote:
> On 2014-08-14 16:03:08 -0400, Steve Singer wrote:
>> I hit the following on 9.4 testing logical decoding.
>>
>>
>> TRAP: FailedAssertion("!(prev_first_lsn < cur_txn->first_lsn)", File:
>> "reorderbuffer.c", Line: 618)
>> LOG: server process (PID 3801) was terminated by signal 6: Aborted
> I saw that recently while hacking around, but I thought it was because
> of stuff I'd added. But apparently not.
>
> Hm. I think I see how that might happen. It might be possible (and
> harmless) if two subxacts of the same toplevel xact have the same
> first_lsn. But if it's not just <= vs < it'd be worse.
>
>> Unfortunately I don't have a core file and I haven't been able to reproduce
>> this.
> Any information about the workload? Any chance you still have the data
> directory around?
I was running the slony regression tests but I ran the same tests
script after a number of times after and the problem didn't reproduce
itself.
The last thing the tests did before the crash was part of the slony
failover process.
I am doing my testing running with all 5 nodes/databases under the same
postmaster (giving something like 20 replication slots open)
A few milliseconds before the one of the connections had just done a
START_REPLICATION SLOT "slon_4_2" LOGICAL 0/32721A58
and then that connection reported the socket being closed,
but because so much was going on concurrently I can't say for sure if
that connection experienced the assert or was closed because another
backend asserted.
I haven't done an initdb since, so I have the data directory but I've
dropped and recreated all of my slots many times since so the wal files
are long gone.
> Greetings,
>
> Andres Freund
>
