On Wed, Jul 10, 2019 at 3:55 AM Jason Madden
<jason.madden@nextthought.com> wrote:
> > On Jul 9, 2019, at 10:45, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > FYI, we're now thinking that the problem here is unrelated to partitions
> > but instead is a bug in EPQ, which is a subsystem that's entered only when
> > a row to be locked/updated is found to have just been updated by some
> > concurrent transaction. See
> >
> > https://www.postgresql.org/message-id/flat/15900-bc482754fe8d7415%40postgresql.org
> >
> > If you're in a position to build a custom version of Postgres, you
> > might try whether the patch proposed in that thread resolves your
> > problem.
>
> Thank you for the update. Unfortunately, I no longer work with that system and aren't able to try to reproduce the
issue.
For the record, that was committed and will appear in the upcoming
maintenance releases.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f5825853e3afdb4df4767d30cbfdd375b45d1f2a
--
Thomas Munro
https://enterprisedb.com