> 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 pgsql-h
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 performance tests, but it was inconclusi
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.
> > >
> > > Seems like it would t
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 tend to be a win if, in fact, the va
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 they're usually not, then it's a l
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 it's a loser. Do
we have any feelin
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 ou
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
>> 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 under
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?
>> 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, REPLI
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. How
> 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
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 stops you from autom
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 replication does
>> not work any more. Am
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
> 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, w
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 repli
While playing around with logical replication, I am confused by the
behavior of REPLICA IDENTITY FULL.
First I created a table having 2 INT columns with no keys. If I
execute ALTER TABLE REPLICA IDENTITY FULL, replication for
UPDATE/DELETE works.
In the session below, port 11002 is the publisher
19 matches
Mail list logo
