> On 2 Oct 2017, at 19:59, Petr Jelinek wrote:
>
>>
>> Program terminated with signal SIGABRT, Aborted.
>> #0 0x7f3608f8ec37 in __GI_raise (sig=sig@entry=6) at
>> ../nptl/sysdeps/unix/sysv/linux/raise.c:56
>> 56../nptl/sysdeps/unix/sysv/linux/raise.c: No
On Wed, Oct 4, 2017 at 8:35 AM, Petr Jelinek
wrote:
> On 02/10/17 18:59, Petr Jelinek wrote:
>>>
>>> Now fix the trigger function:
>>> CREATE OR REPLACE FUNCTION replication_trigger_proc() RETURNS TRIGGER AS $$
>>> BEGIN
>>> RETURN NEW;
>>> END $$ LANGUAGE plpgsql;
On 02/10/17 18:59, Petr Jelinek wrote:
>>
>> Now fix the trigger function:
>> CREATE OR REPLACE FUNCTION replication_trigger_proc() RETURNS TRIGGER AS $$
>> BEGIN
>> RETURN NEW;
>> END $$ LANGUAGE plpgsql;
>>
>> And manually perform at master two updates inside one transaction:
>>
>> postgres=#
I have faced two issues with logical replication.
Repro scenario:
1. start two Postgres instances (I start both at local machine).
2. Initialize pgbench tables at both instances:
pgbench -i -s 10 postgres
3. Create publication of pgbench_accounts table at one node:
create publication pub
On 02/10/17 17:49, Konstantin Knizhnik wrote:
> I have faced two issues with logical replication.
> Reproducing scenario:
>
> 1. start two Postgres instances (I start both at local machine).
> 2. Initialize pgbench tables at both instances:
> pgbench -i -s 10 postgres
> 3. Create publication
I have faced two issues with logical replication.
Reproducing scenario:
1. start two Postgres instances (I start both at local machine).
2. Initialize pgbench tables at both instances:
pgbench -i -s 10 postgres
3. Create publication of pgbench_accounts table at one node:
create