Re: [HACKERS] REPLICA IDENTITY FULL

> Thanks for the feedback. I have committed it after removing the > datumIsEqual() call. Thanks for the patch! I confirmed my examples now work. Best regards, -- Tatsuo Ishii SRA OSS, Inc. Japan English: http://www.sraoss.co.jp/index_en.php Japanese:http://www.sraoss.co.jp -- Sent via

Re: [HACKERS] REPLICA IDENTITY FULL

On 6/23/17 13:14, Alvaro Herrera wrote: > Andres Freund wrote: >> On 2017-06-23 13:05:21 -0400, Alvaro Herrera wrote: >>> Tom Lane wrote: Peter Eisentraut writes: > Any thoughts about keeping datumAsEqual() as a first check? I did some > light

Re: [HACKERS] REPLICA IDENTITY FULL

Andres Freund wrote: > On 2017-06-23 13:05:21 -0400, Alvaro Herrera wrote: > > Tom Lane wrote: > > > Peter Eisentraut writes: > > > > Any thoughts about keeping datumAsEqual() as a first check? I did some > > > > light performance tests, but it was inconclusive.

Re: [HACKERS] REPLICA IDENTITY FULL

On 2017-06-23 13:05:21 -0400, Alvaro Herrera wrote: > Tom Lane wrote: > > Peter Eisentraut writes: > > > Any thoughts about keeping datumAsEqual() as a first check? I did some > > > light performance tests, but it was inconclusive. > > > > Seems like it would

Re: [HACKERS] REPLICA IDENTITY FULL

Tom Lane wrote: > Peter Eisentraut writes: > > Any thoughts about keeping datumAsEqual() as a first check? I did some > > light performance tests, but it was inconclusive. > > Seems like it would tend to be a win if, in fact, the values are > usually equal. If

Re: [HACKERS] REPLICA IDENTITY FULL

Peter Eisentraut writes: > Any thoughts about keeping datumAsEqual() as a first check? I did some > light performance tests, but it was inconclusive. Seems like it would tend to be a win if, in fact, the values are usually equal. If they're usually not, then

Re: [HACKERS] REPLICA IDENTITY FULL

On 6/20/17 00:10, Andres Freund wrote: > On 2017-06-20 11:52:10 +0900, Tatsuo Ishii wrote: >> If my understanding is correct, it would not be easy to fix, no? >> >>> We might be able to refine that, but there is a general problem that >>> without an index and an operator class, we are just doing

Re: [HACKERS] REPLICA IDENTITY FULL

On 2017-06-20 11:52:10 +0900, Tatsuo Ishii wrote: > If my understanding is correct, it would not be easy to fix, no? > > > We might be able to refine that, but there is a general problem that > > without an index and an operator class, we are just doing our random > > best to match the values. I

Re: [HACKERS] REPLICA IDENTITY FULL

>> For example, if the table consists of only INT types, REPLICA IDENTITY >> FULL works with UPDATE/DELETE (i.e. replicated), but if some of them >> are TEXT types, then UPDATE/DELETE does not work. >> >> See up thread for more details. > > Right, but that's just a bug, nothing else. If my

Re: [HACKERS] REPLICA IDENTITY FULL

On 2017-06-20 11:46:13 +0900, Tatsuo Ishii wrote: > >> Yes, that's my understanding too. However, the feature may or may not > >> work depending on the data types of columns, probably I will not > >> recommend users/my customers to use it. > > > > I'm not sure how datatypes are playing into this?

Re: [HACKERS] REPLICA IDENTITY FULL

>> Yes, that's my understanding too. However, the feature may or may not >> work depending on the data types of columns, probably I will not >> recommend users/my customers to use it. > > I'm not sure how datatypes are playing into this? For example, if the table consists of only INT types,

Re: [HACKERS] REPLICA IDENTITY FULL

On 2017-06-20 11:29:06 +0900, Tatsuo Ishii wrote: > > Nothing, and that's what I do. I just think it's a bit fuzzy. Maybe > > I'm misunderstanding the purpose of REPLICA IDENTITY, but I read it as > > saying "this is the replication key for this relation". > > Yes, that's my understanding too.

Re: [HACKERS] REPLICA IDENTITY FULL

> Nothing, and that's what I do. I just think it's a bit fuzzy. Maybe > I'm misunderstanding the purpose of REPLICA IDENTITY, but I read it as > saying "this is the replication key for this relation". Yes, that's my understanding too. However, the feature may or may not work depending on the data

Re: [HACKERS] REPLICA IDENTITY FULL

On 20 June 2017 at 09:47, Andres Freund wrote: > On 2017-06-20 09:45:27 +0800, Craig Ringer wrote: >> 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. > > What

Re: [HACKERS] REPLICA IDENTITY FULL

On 20 June 2017 at 06:53, Peter Eisentraut 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

Re: [HACKERS] REPLICA IDENTITY FULL

On 2017-06-20 09:45:27 +0800, Craig Ringer wrote: > 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. What stops you from automatically using a candidate key if available? - Andres

Re: [HACKERS] REPLICA IDENTITY FULL

> 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. > > We might be able to refine that, but there is a general problem that > without an index and an operator class,

Re: [HACKERS] REPLICA IDENTITY FULL

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