Re: BUG #16233: Yet another "logical replication worker" wasterminated by signal 11: Segmentation fault - Mailing list pgsql-bugs

From Johann du Toit
Subject Re: BUG #16233: Yet another "logical replication worker" wasterminated by signal 11: Segmentation fault
Date
Msg-id CAO7Fzi5c10PSu4ndOMB-a5uf9Ww_rTc4AbcShEkQ38X+X=2eMg@mail.gmail.com
Whole thread Raw
In response to Re: BUG #16233: Yet another "logical replication worker" wasterminated by signal 11: Segmentation fault  (Johann du Toit <johann@winkreports.com>)
List pgsql-bugs
On Mon, 27 Jan 2020 at 11:57, Johann du Toit <johann@winkreports.com> wrote:
>
> On Mon, 27 Jan 2020 at 03:28, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >
> > The stack trace does look the same, but do you have the same triggering
> > condition we identified (that is, fairly wide column values in the
> > subscriber table that are not getting replaced during a
> > logical-replication update? or possibly dropped columns in the
> > subscriber table?)
>
> Thanks Tom.
>
> I don't really think it's the same triggering condition. How wide is
> "fairly wide"?
>
> I also saw in the previous thread you were asking Tomas to show the
> attribute list to check for dropped columns. This is not a long-term
> replication - I'm just trying to do a zero downtime upgrade (which has
> worked fine using pglogical on older postgresql versions). So my
> schema from the publisher is exported and loaded into the subscriber
> "fresh" and no schema changes are done at all.
>
> I was able to get a deb package built using a recent V12 Stable source
> snapshot. I'm trying that as I'm typing this - will report back if it
> crashed out as well.

24 hours later and the full replication succeeded using the latest
V12_STABLE branch patch. I did some tests of the larger tables and the
number of records and columns all seem to match.

So while I still don't think it's the same triggering mechanism, the
patch did solve the problem.

Regards,
-J



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #16236: Invalid escape encoding
Next
From: Dominik Giger
Date:
Subject: Re: BUG #16235: ts_rank ignores match and only considers lowerweighted vector