Re: BUG #15727: PANIC: cannot abort transaction 295144144, it wasalready committed - Mailing list pgsql-bugs

From Andres Freund
Subject Re: BUG #15727: PANIC: cannot abort transaction 295144144, it wasalready committed
Date
Msg-id 20190408164138.izvfg2czwcofg5ev@alap3.anarazel.de
Whole thread Raw
In response to Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Hi,

On 2019-04-08 12:31:37 -0400, Tom Lane wrote:
> BTW, what happens if the concurrent update caused a partition change?
> I imagine we would think the original tuple is now dead, since there's
> no way to chase up to the replacement tuple in the other partition,
> and so we'd abandon our update.  Is this documented?

FWIW, you should get an error:
                if (ItemPointerIndicatesMovedPartitions(tid))
                    ereport(ERROR,
                            (errcode(ERRCODE_T_R_SERIALIZATION_FAILURE),
                             errmsg("tuple to be locked was already moved to another partition due to concurrent
update")));

I think there's tests for the simpler cases. Probably wouldn't hurt to
test that case as another axis for the suite of tests you suggest.

Greetings,

Andres Freund



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed
Next
From: Tom Lane
Date:
Subject: Re: BUG #15741: ERROR: failed to build any 3-way joins