Re: Logical replication without a Primary Key - Mailing list pgsql-hackers

From Joshua D. Drake
Subject Re: Logical replication without a Primary Key
Date
Msg-id 76749b3f-f1f1-72bc-b783-9e53fbe1934a@commandprompt.com
Whole thread Raw
In response to Re: Logical replication without a Primary Key  (Andres Freund <andres@anarazel.de>)
Responses Re: Logical replication without a Primary Key  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 12/07/2017 12:39 PM, Andres Freund wrote:
>
> Not a problem. If you updated both rows, then there's two cases:
> a) the update actually changed the column values. In which case the first per-row
>     change that's replicated updates the first row, but the second one won't
>     again find it as matching in all columns.
> b) the update didn't actually change anything. In which case the same
>     row gets updated twice, but because the column values didn't change,
>     that doesn't matter.

I may be misunderstanding what is said above but if I ran a test:

Publisher:
reptest=# \d foorep
              Table "public.foorep"
  Column | Type | Collation | Nullable | Default
--------+------+-----------+----------+---------
  one    | text |           |          |
  two    | text |           |          |
Publications:
     "reptestpub"

reptest=# select * from foorep;
  one | two
-----+-----
  c   | b
  c   | b
  c   | b
(3 rows)

reptest=# update foorep set one = 'd';
UPDATE 3
reptest=# select * from foorep;
  one | two
-----+-----
  d   | b
  d   | b
  d   | b
(3 rows)

Subscriber before Publisher update:
reptest=# select * from foorep ;
  one | two
-----+-----
  c   | b
  c   | b
  c   | b
(3 rows)

Subscriber after Publisher update:
reptest=# select * from foorep ;
  one | two
-----+-----
  d   | b
  d   | b
  d   | b
(3 rows)

This is the behavior I was expecting. As I said, I may have 
misunderstood the responses but it is acting as I would expect.

Thanks!

JD

-- 
Command Prompt, Inc. || http://the.postgres.company/ || @cmdpromptinc

PostgreSQL centered full stack support, consulting and development.
Advocate: @amplifypostgres || Learn: https://postgresconf.org
*****     Unless otherwise stated, opinions are my own.   *****



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: [HACKERS] Proposal: Local indexes for partitioned table
Next
From: Andres Freund
Date:
Subject: Re: Logical replication without a Primary Key