Re: TRAP: FailedAssertion("!(TransactionIdPrecedesOrEquals

From: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>
To: Erik Rijkers <er(at)xs4all(dot)nl>
Cc: PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: TRAP: FailedAssertion("!(TransactionIdPrecedesOrEquals
Date: 2017-12-20 06:38:56
Message-ID: CAB7nPqT7G9EVW6Zucx9447D5TJ3GhvSuTNqZCOUSxdHs40MUtg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 20, 2017 at 3:33 PM, Erik Rijkers <er(at)xs4all(dot)nl> wrote:
> (logical replication does the initial syncing of the instances one by one
> (sequentially) so it isn't as busy as expected; it just takes a long time)

This is quite different then. I thought that you meant physical
replication with a set of cascading standbys!

> I wrote a simple perl program to test logical replication (attached, FWIW),
> running:
>
> ./cascade.pl --instances=50 --scale=1 --clients=16 --threads=8 --duration=1
> --repeats=3 --waiting=10
>
> This cascade.pl program uses knowledge of my setup so probably won't run
> elsewhere as is but it shows how the failing test was done.

I can get that to work easily at quick glance in my environment.
Likely that will help.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Rafia Sabih 2017-12-20 07:03:03 Re: Shouldn't execParallel.c null-terminate query_string in the parallel DSM?
Previous Message Erik Rijkers 2017-12-20 06:33:45 Re: TRAP: FailedAssertion("!(TransactionIdPrecedesOrEquals