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