Re: [BUG]Update Toast data failure in logical replication - Mailing list pgsql-hackers

From Dilip Kumar
Subject Re: [BUG]Update Toast data failure in logical replication
Date
Msg-id CAFiTN-tXm1rjhoN+rfEEsc7JW59yxWXM9vBGfy9nTTqVKj3cUQ@mail.gmail.com
Whole thread Raw
In response to Re: [BUG]Update Toast data failure in logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: [BUG]Update Toast data failure in logical replication  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Fri, Jul 23, 2021 at 8:58 AM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> Okay, thanks. I think one point we need to consider here is that on
> the subscriber side, we use dirtysnapshot to search the key, so we
> need to ensure that we don't fetch the wrong data. I am not sure what
> will happen when by the time we try to search the tuple in the
> subscriber-side for the update, it has been removed and re-inserted
> with the same values by the user. Do we find the newly inserted tuple
> and update it? If so, can it also happen even if logged the unchanged
> old_key_tuple as the patch is doing currently?
>

I was thinking more about this idea, but IMHO, unless we send the key
toasted tuple from the publisher how is the subscriber supposed to
fetch it.  Because that is the key value for finding the tuple on the
subscriber side and if we haven't sent the key value, how are we
supposed to find the tuple on the subscriber side?

-- 
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Inaccurate error message when set fdw batch_size to 0
Next
From: vignesh C
Date:
Subject: Re: Added schema level support for publication.