Re: pglogical most basic setup for logical replication
От | Craig Ringer |
---|---|
Тема | Re: pglogical most basic setup for logical replication |
Дата | |
Msg-id | CAMsr+YE9oT8EGSzWgny+H1aHT0D3dwqXfAoXU7Y3wbK+-5rV-Q@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pglogical most basic setup for logical replication (Sebastien Diemer <sebastien.diemer@polyconseil.fr>) |
Список | pgsql-hackers |
On 26 January 2016 at 19:18, Sebastien Diemer <sebastien.diemer@polyconseil.fr> wrote:
It sounds like you must be running on PostgreSQL 9.4.Indeed I am on PostgreSQL 9.4, I omitted this important point.
I'll update the docs to mention the extra step on 9.4.
You'll need to drop the subscriber database and re-create it. Use a new node name.Seems to work but I still do not really understand what was wrong in the first place though.Thanks for your help Craig !
It's because internally pglogical relies on pg_dump and pg_restore to set up the initial database state. If it fails partway through a pg_restore there's no sensible way to undo those changes, especially since we have to do it in a number of steps to achieve a partial restore.
A cleaner handling of this really requires the ability to use pg_dump's functionality over a normal protocol connection from SQL, or at least as a library.
The error should probably get a HINT to say that an incomplete restore means the DB may have to be dropped and recreated.
It's all a bit messy, since we support multiple upstreams and support writes directly into the downstream. So you actually can't always just drop the downstream. A really good solution to this needs the ability to compare various objects (type definitions, tables, etc), the ability to extract just a required subset of dependencies from a database and other complexities.
В списке pgsql-hackers по дате отправления: