vignesh C writes:
> On Fri, 6 Jan 2023 at 04:32, Tom Lane wrote:
>> Hm. I spent some time cleaning up this patch, and found that there's
>> still a problem. ISTM that the row with value "3" ought to end up
>> in the subscriber's sch2.t1 table, but it does not: the attached
>> test script fails
On Fri, 6 Jan 2023 at 04:32, Tom Lane wrote:
>
> vignesh C writes:
> > On Thu, 5 Jan 2023 at 03:17, Tom Lane wrote:
> >> The bigger picture here though is that in examples such as the one
> >> you gave at the top of the thread, it's not very clear to me that
> >> there's *any* principled behavio
vignesh C writes:
> On Thu, 5 Jan 2023 at 03:17, Tom Lane wrote:
>> The bigger picture here though is that in examples such as the one
>> you gave at the top of the thread, it's not very clear to me that
>> there's *any* principled behavior. If the connection between publisher
>> and subscriber
On Thu, 5 Jan 2023 at 03:17, Tom Lane wrote:
>
> vignesh C writes:
> > [ v3-0001-Fix-for-invalidating-logical-replication-relation.patch ]
>
> (btw, please don't send multiple patch versions with the same number,
> it's very confusing.)
Since it was just rebasing on top of HEAD, I did not change
vignesh C writes:
> [ v3-0001-Fix-for-invalidating-logical-replication-relation.patch ]
(btw, please don't send multiple patch versions with the same number,
it's very confusing.)
I looked briefly at this patch. I wonder why you wrote a whole new
callback function instead of just using rel_sync
On Sat, Mar 12, 2022 at 1:29 PM vignesh C wrote:
>
> On Fri, Dec 3, 2021 at 3:21 PM vignesh C wrote:
> >
> > On Fri, Dec 3, 2021 at 1:13 PM Michael Paquier wrote:
> > >
> > > On Thu, Aug 26, 2021 at 09:00:39PM +0530, vignesh C wrote:
> > > > The previous patch was failing because of the recent t
On Fri, Dec 3, 2021 at 3:21 PM vignesh C wrote:
>
> On Fri, Dec 3, 2021 at 1:13 PM Michael Paquier wrote:
> >
> > On Thu, Aug 26, 2021 at 09:00:39PM +0530, vignesh C wrote:
> > > The previous patch was failing because of the recent test changes made
> > > by commit 201a76183e2 which unified new a
On Fri, Dec 3, 2021 at 1:13 PM Michael Paquier wrote:
>
> On Thu, Aug 26, 2021 at 09:00:39PM +0530, vignesh C wrote:
> > The previous patch was failing because of the recent test changes made
> > by commit 201a76183e2 which unified new and get_new_node, attached
> > patch has the changes to handle
On Thu, Aug 26, 2021 at 09:00:39PM +0530, vignesh C wrote:
> The previous patch was failing because of the recent test changes made
> by commit 201a76183e2 which unified new and get_new_node, attached
> patch has the changes to handle the changes accordingly.
Please note that the CF app is complai
On Fri, Jul 16, 2021 at 10:51 PM vignesh C wrote:
>
> On Sat, Jul 3, 2021 at 11:23 AM Dilip Kumar wrote:
> >
> > On Fri, Jul 2, 2021 at 12:03 PM Dilip Kumar wrote:
> > >
> > > Yeah, this looks like a bug. I will look at the patch.
> > >
> >
> > While looking into this, I think the main cause of
On Sat, Jul 3, 2021 at 11:23 AM Dilip Kumar wrote:
>
> On Fri, Jul 2, 2021 at 12:03 PM Dilip Kumar wrote:
> >
> > Yeah, this looks like a bug. I will look at the patch.
> >
>
> While looking into this, I think the main cause of the problem is that
> schema rename does not invalidate the relation
On Fri, Jul 2, 2021 at 12:03 PM Dilip Kumar wrote:
>
> Yeah, this looks like a bug. I will look at the patch.
>
While looking into this, I think the main cause of the problem is that
schema rename does not invalidate the relation cache right? I also
tried other cases e.g. if there is an open cu
On Fri, Jul 2, 2021 at 11:11 AM vignesh C wrote:
>
> Hi,
>
> I found a strange behavior when there is an insert after renaming the
> schema. The test steps for the same are given below, Here after the
> schema is renamed, the renamed schema table data should not be sent,
> but the data was being s
13 matches
Mail list logo
