Re: Segmentation Fault in logical decoding get/peek API

On 02/20/2018 06:55 PM, Andres Freund wrote:
> Hi,
> 
> On 2018-02-19 05:20:14 -0700, Sudalai wrote:
>> PostgreSQL backend crashing with segmentation fault 11, while consuming big
>> transaction changes using pg_logical_slot_(peek|get)_changes.  We are using
>> postgresql version 9.5.10.
> 
> Just to be sure, could you check that 9.5.11 shows the same problem?
> 
>> About the big transaction : pg_xlog_dump shows 161426 records, and it spread
>> across 3 WAL files. 
>>
>> BackTace of the backend : 
>>
>> Program received signal SIGSEGV, Segmentation fault.
>> ReorderBufferCommit (rb=0xd17dc8, xid=<value optimized out>,
>> commit_lsn=7224098593984, end_lsn=<value optimized out>, commit_time=<value
>> optimized out>, origin_id=<value optimized out>, origin_lsn=0) at
>> /home/test/compile/../postgresql-9.5.10/src/backend/replication/logical/reorderbuffer.c:1380

This very much seems like a custom PostgreSQL build (judging by the
paths in the backtrace), so I wonder what configure options were used.
It's not clear if this is a production of testing evironment, but if you
could rebuild with debugging symbols / without optimizations, that would
be helpful (it would get rid of some of the "optimized out" stuff).

>> 1380                        change->action = REORDER_BUFFER_CHANGE_INSERT;
>>

Hmmm, this would mean it's failing here:

    case REORDER_BUFFER_CHANGE_INTERNAL_SPEC_CONFIRM:

        /*
         * Confirmation for speculative insertion arrived. Simply
         * use as a normal record. It'll be cleaned up at the end
         * of INSERT processing.
         */
        Assert(specinsert->data.tp.oldtuple == NULL);
        change = specinsert;
        change->action = REORDER_BUFFER_CHANGE_INSERT;

And if it's segfaulting, it has to mean specinsert is NULL. So either we
never got REORDER_BUFFER_CHANGE_INTERNAL_SPEC_INSERT, or we threw it
away in the "change_done" part. Seems strange in both cases.

Sudalai, are you using speculative inserts in the transaction?

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services