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

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>
To: r.zharkov@postgrespro.ru, pgsql-bugs@lists.postgresql.org
Date: 2019-04-02T15:29:25Z
Lists: pgsql-bugs
Hi,

On 2019-04-02 10:30:15 +0000, PG Bug reporting form wrote:
> The following bug has been logged on the website:
> 
> Bug reference:      15727
> Logged by:          Roman Zharkov
> Email address:      r.zharkov@postgrespro.ru
> PostgreSQL version: Unsupported/Unknown
> Operating system:   Ubuntu 5.4.0-6ubuntu1~16.04.10
> Description:        
> 
> Hello,
> Our test server crashed while benchmarking connection pooler called Yandex
> Odyssey.

What's the exact workload? Just pgbench?


> There is no debugging info in the code dump now, because it takes few hours
> to reproduce the error. We will try to reproduce the error with debugging
> info.

Unfortunately a backtrace is probably not going to help up much, I'm
afraid. The issue likely is triggered at an earlier state than the error
thrown here.


> Server version - PostgreSQL 12devel-master, commit - bb76134 on
> x86_64-pc-linux-gnu, compiled by gcc (Ubuntu 5.4.0-6ubuntu1~16.04.10) 5.4.0
> 20160609, 64-bit
> 
> The error does not reproduce on PostgreSQL 12devel-master, commit -
> 2fadf24
> 
> 2019-04-01 15:27:38.829 +07 [7524] ERROR:  unexpected table_lock_tuple
> status: 1

Hm, so that appears to be related to my changes. Could you run this with
log_error_verbosity=verbose, so we know which of the codepaths this
hits?  Apparently we're encountering an invisible tuple somewhere, which
I thought was not possible (hence the error) - previously we just
ignored that.


> 2019-04-01 15:27:38.829 +07 [7524] STATEMENT:  UPDATE pgbench_accounts SET
> abalance = 1 WHERE aid = 1;
> 2019-04-01 15:27:38.829 +07 [7524] PANIC:  cannot abort transaction
> 400048276, it was already committed

But that's probably a separate issue.

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.