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