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