Re: logical decoding - reading a user catalog table - Mailing list pgsql-hackers

From Steve Singer
Subject Re: logical decoding - reading a user catalog table
Date
Msg-id BLU436-SMTP66CFD8754C0E05B07F33B6DC8A0@phx.gbl
Whole thread Raw
In response to Re: logical decoding - reading a user catalog table  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: logical decoding - reading a user catalog table  (Steve Singer <steve@ssinger.info>)
List pgsql-hackers
On 11/13/2014 02:44 PM, Andres Freund wrote:
> Hi Steve,

> If it still happens, could you send me instructions of how to reproduce
> the problem after cloning the necessary source repositories? It's quite
> hard to validate a possible fix otherwise.

1. Install PG 9.4

2. Perform an initdb   max_connections = 200   wal_level=logical   max_walsenders=50   wal_keep_segments = 100
wal_sender_timeout= 600s   max_replication_slots = 120
 



Create a user slon with superuser
create a user test
(set passwords for them you'll use them later)

Configure pg_hba.conf to allow slon to connect as a replication user


3. Download slony from github (https://github.com/ssinger/slony1-engine.git)   checkout  the branch
logical_remote_helper   ./configure --with-pgconfigdir=/path_to_your_pgcbindir
 
make
make install

4. Download clustertest & compile clustertest from 
(https://github.com/clustertest/clustertest-framework).
5. In the slony source tree cd to the clustertest directory
6. cp conf/disorder.properties.sample to conf/disorder.properties
Edit the file to have the correct paths, ports, users, passwords.

7 cp conf/java.properties.sample to conf/java.properties edit the file 
to point at the JAR you downloaded earlier.

I run with all 5 databases on the same PG cluster. Performance will be 
much better with 5 different clusters, but I recommend trying to emulate 
my configuration as much as possible to replicate this

To run the tests then do
./run_all_disorder_tests.sh


At the moment (commit df5acfd1a3) is configured to just run the Failover 
node test cases where I am seeing this not the entire suite.

It typically takes between 30 minutes to an hour to run though.

I installed things following the above steps on a different system than 
my usual development laptop and I have been unable to reproduce the 
error so for (on that system).  But I am still able to reproduce it on 
occasion on my normal development laptop.



> Greetings,
>
> Andres Freund
>




pgsql-hackers by date:

Previous
From: Christian Ullrich
Date:
Subject: Re: [GSoC2014] Patch ALTER TABLE ... SET LOGGED
Next
From: Pavel Stehule
Date:
Subject: Re: printing table in asciidoc with psql