RE: [Incident report]Backend process crashed when executing 2pc transaction

From: Ranier Vilela <ranier_gyn(at)hotmail(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: [Incident report]Backend process crashed when executing 2pc transaction
Date: 2019-11-28 17:37:55
Message-ID: MN2PR18MB2927B6BA935EBA277C855483E3470@MN2PR18MB2927.namprd18.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Marco wrote:
> One interesting thing is the prepared transaction name generated by
> the coordinator, which follows the form: citus_<coordinator node
> id>_<pid>_<server-wide transaction number >_<prepared transaction
> number in session>. The server-wide transaction number is a 64-bit
> counter that is kept in shared memory and starts at 1. That means that
> over 4 billion (4207001212) transactions happened on the coordinator
> since the server started, which quite possibly resulted in 4 billion
> prepared transactions on this particular server. I'm wondering if some
> counter is overflowing.

Amit wrote:
>Interesting. This does kind of gets us closer to figuring out what
>might have gone wrong, but hard to tell without the core dump at hand.

If something is corrupting memory rarely. It would be interesting to consider all the possibilities.
The MemSet function has an error alert on line 785 (twophase.c).
The size the var "_vstart" buffer, is not multiple size of the type long.
Maybe it's filling more than it should.

Ranier Vilela

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2019-11-28 17:46:44 Re: Memory-Bounded Hash Aggregation
Previous Message Tom Lane 2019-11-28 16:11:44 Re: allow_system_table_mods stuff