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: r.zharkov@postgrespro.ru
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-bugs@lists.postgresql.org
Date: 2019-04-02T17:11:52Z
Lists: pgsql-bugs 
Hi,

On 2019-04-03 00:04:15 +0700, r.zharkov@postgrespro.ru wrote:
> pgbench connects to the database through the connection pooller called
> Odyssey.
> We use pool of 16 or 32 backends.
> We run four series of pgbench tests with different connections count ( 100,
> 150, 200, ... , 1000 )
> Three series with pool size 16 runs normally.
> But fourth series fails with 200-300 connections. It took about five hours
> to reproduce the error this time.
> 
> Here is the little piece of the pgbench log:
> 
> Bench start
> Tue Apr  2 14:43:12 UTC 2019
> Timestamp 1554216192
> transaction type: multiple scripts
> scaling factor: 1

Is this the actual scaling factor? Did you create the pgbench database
with foreign keys?

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.