From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
---|---|
To: | Sudalai <sudalait2(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: Segmentation Fault in logical decoding get/peek API |
Date: | 2018-02-21 14:31:04 |
Message-ID: | 9fe0a6de-d204-9067-4eba-dd686077dd89@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 02/21/2018 08:18 AM, Sudalai wrote:
>
>
>>> 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.
>
> Yes, specinsert is NULL.
>
>>> Sudalai, are you using speculative inserts in the transaction?
> Yes . We have done ON CONFLICT DO NOTHING .
>
>
> Is it correct to add below check ,
> if(specinsert == NULL ){
> goto change_done;
> }
> before , Assert(specinsert->data.tp.oldtuple == NULL); to fix segfault ?
>
That seems unlikely to fix the root cause - more likely it's going to
mask it in some strange way. We need to understand why it does happen
(i.e. specinsert is not expected to be NULL here).
It would really help if you could provide a self-contained test case
demonstrating the issue, as mentioned by Andres.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-02-21 15:08:12 | Re: pg_upgrade and materialized views |
Previous Message | Victor Yegorov | 2018-02-21 09:46:30 | Re: pg_upgrade and materialized views |