| From: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | Tatsuo Ishii <ishii(at)sraoss(dot)co(dot)jp>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de> |
| Subject: | Re: REPLICA IDENTITY FULL |
| Date: | 2017-06-20 01:45:27 |
| Message-ID: | CAMsr+YHfX3vpm=1pVSxRbQH4Cx8DjqkD066XvFFi6Ex9Ssh--w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 20 June 2017 at 06:53, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
> On 6/18/17 23:11, Tatsuo Ishii wrote:
>> While playing around with logical replication, I am confused by the
>> behavior of REPLICA IDENTITY FULL.
>
>> However, if a table has text columns, UPDATE/DELETE replication does
>> not work any more. Am I missing something?
>
> This is apparently because for replica identity full the comparison of
> the search key against the tuple value goes through datumIsEqual(),
> which doesn't work for TOAST values.
Personally I think REPLICA IDENTITY FULL conflates two related things.
One is "record the whole old value of the tuple in xlog so logical
decoding can access it".
Quite separately, there is "treat the full tuple as the replica identity key".
I frequently want to be able to use REPLICA IDENTITY DEFAULT, but also
record the whole old tuple not just keys, so they can be used in
conflict processing etc.
--
Craig Ringer http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2017-06-20 01:47:02 | Re: Get stuck when dropping a subscription during synchronizing table |
| Previous Message | Craig Ringer | 2017-06-20 01:43:24 | Re: PATCH: Batch/pipelining support for libpq |