Re: [Gnumed-devel] database replication with bucardo

[Karsten Hilbert]

On Wed, Jul 04, 2012 at 08:25:30PM +0200, Slappinjohn wrote:

> current status:
> 
> due to the bad documentation of bucardo it took a while, but a got a
> completely set up sync. I had to add some tables for bucardo manually
> (so the database schema is altered through the bucardo installation too.
> This will need to adopt the checksum manually for users who will use
> this feature!).

Unless those tables MUST reside in either of the schemata

        'dem', 'clin', 'blobs', 'cfg', 'ref', 'i18n', 'bill'

GNUmed won't care :-)

That is because GNUmed only verifies existence of the table
structure it needs. It does not verify absence of other
database objects outside its own schemata.

> I've done some encounter work and document stuff just as normal with a
> test patient and checked it on the other database. Everything seems
> there, but on entering the patient gnumed died with an error (log
> appended) GNUmed or bucardo related???

Both, actually. GNUmed does not provide a nice error message
for something failing having been caused by something not
GNUmed :-)

What happens here is that GNUmed tries to write a provider
inbox message which fails because the PK PostgreSQL gets
from the associated PK sequence is already there.

Now, this is either due to Bucardo having screwed up the
sync between table and sequence on either end or else
something else having screwed up the sequence on either end.

Let's see what the table itself sayeth:

        select max(pk) from dem.message_inbox;

And then what the sequence thinks about itself:

        select * from dem.provider_inbox_pk_seq;

"max(pk)" and ".last_value" should agree.

Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346