Horton

Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: r.zharkov@postgrespro.ru, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-bugs@lists.postgresql.org
Date: 2019-04-07T20:33:15Z
Lists: pgsql-bugs

Attachments

Hi,

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
not backpatch?

Greetings,

Andres Freund

Commits

  1. Fix GetNewTransactionId()'s interaction with xidVacLimit.

  2. Fix example in comment.

  3. Fix EvalPlanQualStart to handle partitioned result rels correctly.

  4. Fix a number of issues around modifying a previously updated row.

  5. Use FullTransactionId for the transaction stack.

  6. Add basic infrastructure for 64 bit transaction IDs.

  7. tableam: Add tuple_{insert, delete, update, lock} and use.

  8. Throw error if expiring tuple is again updated or deleted.