From: | Thomas Munro <thomas(dot)munro(at)gmail(dot)com> |
---|---|
To: | Jason Madden <jason(dot)madden(at)nextthought(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re: BUG #15720: `executor could not find named tuplestore ABC` in AFTER DELETE trigger referencing OLD TABLE as ABC |
Date: | 2019-07-09 22:46:37 |
Message-ID: | CA+hUKGKR3Eh7JM+P_wc=8a2c91PqfwzOU_HGK_AUCEwK16NP1w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On Wed, Jul 10, 2019 at 3:55 AM Jason Madden
<jason(dot)madden(at)nextthought(dot)com> wrote:
> > On Jul 9, 2019, at 10:45, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
--
Thomas Munro
https://enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-07-09 23:04:14 | Re: perl issue |
Previous Message | Thomas Munro | 2019-07-09 22:43:28 | Re: BUG #15900: `executor could not find named tuplestore` in triggers with transition table and row locks |