|From:||Andres Freund <andres(at)anarazel(dot)de>|
|To:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|Cc:||r(dot)zharkov(at)postgrespro(dot)ru, Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org|
|Subject:||Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
On 2019-04-06 16:10:37 -0700, Andres Freund wrote:
> On 2019-04-06 10:10:25 -0700, Andres Freund wrote:
> > I noticed that we say
> > + ereport(ERROR,
> > + (errcode(ERRCODE_TRIGGERED_DATA_CHANGE_VIOLATION),
> > + errmsg("tuple to be updated was already modified by an operation triggered by the current command"),
> > in the ExecDelete() case (that's not new). Which seems odd.
> My inclination is to fix this in master, but not backpatch. I did in the
> current version of the patch, because it made it easier to verify my
> tests actually work.
Attached patch does so.
> One bigger question, around precisely that error, I have is that fixing
> this bug led me to add tests for the codepath. What I noticed is that
> the current version of the patch detects the above error even if we
> first have to follow the update chain, whereas previously that case was
> just blindly ignored. Which seems hard to defend to me?
> [ long explanation ]
> It seems mighty finnicky to fix this in < v12 (as the error would need
> to happen in the guts of EvalPlanQualFetch() rather than in
> ExecUpdate/Delete) - so I'm inclined to just fix it in master.
Attached patch now errors out.
Patch with tests attached. Tom, any chance you could comment on whether
you think it's sensible to make these behaviour changes in master, but
|Next Message||PG Bug reporting form||2019-04-08 02:59:52||BUG #15739: PgAdmin4 4.4 does not work with latest psycopg2 (2.8.1)|
|Previous Message||Andres Freund||2019-04-06 23:10:37||Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed|