On Mon, Jul 17, 2023 at 11:51 AM Önder Kalacı wrote:
>
>> >
>> > The last line seems repetitive to me. So, I have removed it. Apart
>> > from that patch looks good to me. Sergie, Peter, and others, any
>> > thoughts?
>>
>> The v5 patch LGTM.
>>
>
> Overall looks good to me as well. Please
On Mon, Jul 17, 2023 at 11:51 AM Önder Kalacı wrote:
>
>> >
>> > The last line seems repetitive to me. So, I have removed it. Apart
>> > from that patch looks good to me. Sergie, Peter, and others, any
>> > thoughts?
>>
>> The v5 patch LGTM.
>>
>
> Overall looks good to me as well. Please
Hi,
>
> > The last line seems repetitive to me. So, I have removed it. Apart
> > from that patch looks good to me. Sergie, Peter, and others, any
> > thoughts?
>
> The v5 patch LGTM.
>
>
Overall looks good to me as well. Please consider the following as an
optional improvement.
My only minor
On Sat, Jul 15, 2023 at 2:10 PM Amit Kapila wrote:
>
> On Fri, Jul 14, 2023 at 2:15 PM Hayato Kuroda (Fujitsu)
> wrote:
> >
> > > > I think it's appropriate to add on the restrictions page. (But
> > > > mentioning that this
> > > restriction is only for subscriber)
> > > >
> > > > If the list
On Fri, Jul 14, 2023 at 2:15 PM Hayato Kuroda (Fujitsu)
wrote:
>
> > > I think it's appropriate to add on the restrictions page. (But mentioning
> > > that this
> > restriction is only for subscriber)
> > >
> > > If the list were larger, then the restrictions page could be divided into
> > >
Dear Amit, Sergei,
> > I think it's appropriate to add on the restrictions page. (But mentioning
> > that this
> restriction is only for subscriber)
> >
> > If the list were larger, then the restrictions page could be divided into
> > publisher
> and subscriber restrictions. But not for one
On Tue, Jul 11, 2023 at 2:17 PM Sergei Kornilov wrote:
>
> I think it's appropriate to add on the restrictions page. (But mentioning
> that this restriction is only for subscriber)
>
> If the list were larger, then the restrictions page could be divided into
> publisher and subscriber
Hello
I think it's appropriate to add on the restrictions page. (But mentioning that
this restriction is only for subscriber)
If the list were larger, then the restrictions page could be divided into
publisher and subscriber restrictions. But not for one very specific
restriction.
regards,
On Tue, Jul 11, 2023 at 12:30 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear Amit,
>
> > Isn't the same true for the hash operator class family as well?
>
> True. I didn't write it on purpose because I didn't know the operator which is
> operator class for BTree but not for Hash. But I agreed to
Dear Amit,
> After seeing this, I am thinking about whether we add this restriction
> on the Subscription page [1] or Restrictions page [2] as proposed. Do
> you others have any preference?
>
> [1] -
> https://www.postgresql.org/docs/devel/logical-replication-subscription.html
> [2] -
>
Dear Sergei,
Thank you for giving comment!
The restriction is only for subscriber: the publisher can publish the changes
to downstream under the condition, but the subscriber cannot apply that.
> So, I suggest to mention subscriber explicitly:
>
> + class of Btree, then UPDATE and
> DELETE
Dear Amit,
> Isn't the same true for the hash operator class family as well?
True. I didn't write it on purpose because I didn't know the operator which is
operator class for BTree but not for Hash. But I agreed to clarify it.
> Can we
> slightly change the line as: "... the table includes an
On Mon, Jul 10, 2023 at 7:26 PM Sergei Kornilov wrote:
>
> >> Is this restriction only for the subscriber?
> >>
> >> If we have not changed the replica identity and there is no primary key,
> >> then we forbid update and delete on the publication side (a fairly common
> >> usage error at the
>> Is this restriction only for the subscriber?
>>
>> If we have not changed the replica identity and there is no primary key,
>> then we forbid update and delete on the publication side (a fairly common
>> usage error at the beginning of using publications).
>> If we have replica identity FULL
On Mon, Jul 10, 2023 at 4:33 PM Sergei Kornilov wrote:
>
> Is this restriction only for the subscriber?
>
> If we have not changed the replica identity and there is no primary key, then
> we forbid update and delete on the publication side (a fairly common usage
> error at the beginning of
On Mon, Jul 10, 2023 at 2:33 PM Hayato Kuroda (Fujitsu)
wrote:
>
If the published table specifies
+ REPLICA
IDENTITY FULL
+ but the table includes an attribute whose datatype is not an operator
+ class of Btree,
Isn't the same true for the hash operator class family as well?
Dear Peter,
Thanks for checking! PSA new version.
> 1.
> SUGGESTION (minor reword)
> If the published table specifies REPLICA IDENTITY
> FULL but the table includes an attribute whose datatype is
> not an operator class of Btree, then UPDATE and
> DELETE operations cannot be replicated. To make
On Mon, Jul 10, 2023 at 1:33 PM Hayato Kuroda (Fujitsu)
wrote:
>
> Dear hackers,
>
> This is a fork thread from [1]. While analyzing codes I noticed that UPDATE
> and
> DELETE cannot be replicated when REPLICA IDENTITY is FULL and the table has
> datatype
> which does not have the operator
Dear hackers,
This is a fork thread from [1]. While analyzing codes I noticed that UPDATE and
DELETE cannot be replicated when REPLICA IDENTITY is FULL and the table has
datatype
which does not have the operator class of Btree. I thnk this restriction is not
documented but should be. PSA the
19 matches
Mail list logo
