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
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 |