Hi,
> - I definitely got the same segfault on a commit after 10.4 - 0bb28ca
> - I am now getting a different segfault on 10.5 - but I need another set
> of eyes to verify I am not compiling it wrong
>
> After decoding successfully for awhile, now I get an immediate segfault
> upon peek_changes. First of all, here is the backtrace:
But to confirm, with 10.6 that's gone?
> $ sudo -u postgres gdb -q -c /san/<cluster>/pgdata/core
> /usr/lib/postgresql/10.5/bin/postgres
> Reading symbols from /usr/lib/postgresql/10.5/bin/postgres...done.
> [New LWP 22699]
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> Core was generated by `postgres: <cluster>: jfinzel foo_db
> 10.7.111.37(52316) FETCH'.
> Program terminated with signal SIGABRT, Aborted.
Note that this is not a segfault, it's an assertion that failed.
> #0 0x00007eff42d54428 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> (gdb) bt
> #0 0x00007eff42d54428 in raise () from /lib/x86_64-linux-gnu/libc.so.6
> #1 0x00007eff42d5602a in abort () from /lib/x86_64-linux-gnu/libc.so.6
> #2 0x0000000000a45f9c in ExceptionalCondition (conditionName=0xc2d688
> "!(prev_first_lsn < cur_txn->first_lsn)", errorType=0xc2d404
> "FailedAssertion", fileName=0xc2d478 "reorderbuffer.c", lineNumber=688) at
> assert.c:54
If it's not gone with 10.6, could you print the two variables in that
expression?
> # Install Extensions
> cd $HOME/pgl_ddl_deploy
> make clean
> sudo "PATH=$PATH" make install
> cd $HOME/pglogical_ticker
> make clean
> sudo "PATH=$PATH" make install
> cd $HOME/pg_fact_loader
> make clean
> sudo "PATH=$PATH" make install
It's entirely possible that one of those extensions does something to
violate WAL logging rules :/
Greetings,
Andres Freund