Marco wrote:
> One interesting thing is the prepared transaction name generated by
> the coordinator, which follows the form: citus_ id>___ 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
Hi Marco,
On Thu, Nov 28, 2019 at 5:02 PM Marco Slot wrote:
>
> On Thu, Nov 28, 2019 at 6:18 AM Amit Langote wrote:
> > Interesting. Still, I think you'd be in better position than anyone
> > else to come up with reproduction steps for vanilla PostgreSQL by
> > analyzing the stack trace if and
On Thu, Nov 28, 2019 at 6:18 AM Amit Langote wrote:
> Interesting. Still, I think you'd be in better position than anyone
> else to come up with reproduction steps for vanilla PostgreSQL by
> analyzing the stack trace if and when the crash next occurs (or using
> the existing core dump). It's
On Thu, Nov 28, 2019 at 2:00 PM LIANGBO wrote:
>
> Hello:
>
> > Have you considered *also* reporting this to Citus developers, because
> > while the crash seems to have occurred in the core PostgreSQL code they may
> > have a better chance reproducing this if at all.
>
> I've sent this issue to
On Thu, Nov 28, 2019 at 01:24:00PM +0900, Amit Langote wrote:
> Have you considered *also* reporting this to Citus developers, because
> while the crash seems to have occurred in the core PostgreSQL code
> they may have a better chance reproducing this if at all.
Hard to fully conclude with the
Hello,
On Wed, Nov 27, 2019 at 8:59 PM LIANGBO wrote:
> I've met the following problem in our product environment. We tried to
> reproduce the problem, but because of the low probability of occurrence, we
> could not reproduce it.
> 1. phenomenon
> Backend process crashed when executing 2pc
