| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, r(dot)zharkov(at)postgrespro(dot)ru, 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 |
| Date: | 2019-04-08 16:41:38 |
| Message-ID: | 20190408164138.izvfg2czwcofg5ev@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-04-08 20:13:42 | Re: BUG #15741: ERROR: failed to build any 3-way joins |
| Previous Message | Tom Lane | 2019-04-08 16:31:37 | Re: BUG #15727: PANIC: cannot abort transaction 295144144, it was already committed |