On 20/12/16 10:41, Erik Rijkers wrote: > On 2016-12-20 09:43, Petr Jelinek wrote: > >> Thanks, this was very useful. We had wrong attribute index arithmetics >> in the place where we verify that replica identities match well enough. > > Well, I spent a lot of time on the whole thing so I am glad it's not just > something stupid I did :)
Yeah sadly it was something stupid I did ;) > >> BTW that script you have for testing has 2 minor flaws in terms of >> pgbench_history - the order by is not unique enough (adding mtime or >> something helps) > > yes, in another version I did > ALTER TABLE pgbench_history ADD COLUMN hid SERIAL PRIMARY KEY. > I suppose that's the best way (adding mtime doesn't work; apparently mtime > gets repeated too). (I have now added that alter table-statement again.) > >> and second, the pgbench actually truncates the >> pgbench_history unless -n is added to command line. > > ok, -n added. > >> So attached is v15, which fixes this and the >> ERROR: unexpected command tag "PUBLICATION >> as reported by Steve Singer (plus tab completion fixes and doc fixes). > > Great. It seems to fix the problem: I just an an unprecidented > 5-minute run with correct replication. > Great, thanks. > The first compile gave the attached diffs in the publication regression > test; subsequent > compiles went OK (2x). If I have time later today I'll try to reproduce > that one FAILED test > but maybe you can see immediately what's wrong there . Seems like tables are just returned in different order but otherwise it's ok. I guess a way to make this more stable would be to add order by in the query psql sends to get the list of tables in the publication. -- Petr Jelinek http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers