On Fri, Jul 23, 2021 at 8:36 AM Amit Kapila <amit.kapil...@gmail.com> wrote:
> On Fri, Jul 23, 2021 at 8:29 AM Amit Kapila <amit.kapil...@gmail.com> > wrote: > > > > On Thu, Jul 22, 2021 at 8:06 PM Dilip Kumar <dilipbal...@gmail.com> > wrote: > > > > > > On Thu, Jul 22, 2021 at 5:15 PM Amit Kapila <amit.kapil...@gmail.com> > wrote: > > > > > > > > On Tue, Jul 20, 2021 at 4:33 PM Dilip Kumar <dilipbal...@gmail.com> > wrote: > > > > > > > > > > On Tue, Jul 20, 2021 at 3:43 PM Tomas Vondra > > > > > <tomas.von...@enterprisedb.com> wrote: > > > > > > > > > > > > Do we log the TOAST-ed values that were not updated? > > > > > > > > > > No, we don't, I have submitted a patch sometime back to fix that > [1] > > > > > > > > > > > > > That patch seems to log WAL for key unchanged columns. What about if > > > > unchanged non-key columns? Do they get logged as part of the new > tuple > > > > or is there some other way we can get those? If not, then we need to > > > > probably think of restricting filter clause in some way. > > > > > > But what sort of restrictions? I mean we can not put based on data > > > type right that will be too restrictive, > > > > > > > Yeah, data type restriction sounds too restrictive and unless the data > > is toasted, the data will be anyway available. I think such kind of > > restriction should be the last resort but let's try to see if we can > > do something better. > > > > > other option is only to allow > > > replica identity keys columns in the filter condition? > > > > > > > Yes, that is what I had in mind because if key column(s) is changed > > then we will have data for both old and new tuples. But if it is not > > changed then we will have it probably for the old tuple unless we > > decide to fix the bug you mentioned in a different way in which case > > we might either need to log it for the purpose of this feature (but > > that will be any way for HEAD) or need to come up with some other > > solution here. I think we can't even fetch such columns data during > > decoding because we have catalog-only historic snapshots here. Do you > > have any better ideas? > > > > BTW, I wonder how pglogical can handle this because if these unchanged > toasted values are not logged in WAL for the new tuple then how the > comparison for such columns will work? Either they are forcing WAL in > some way or don't allow WHERE clause on such columns or maybe they > have dealt with it in some other way unless they are unaware of this > problem. > > The column comparison for row filtering happens before the unchanged toast columns are filtered. Unchanged toast columns are filtered just before writing the tuple to output stream. I think this is the case both for pglogical and the proposed patch. So, I can't see why the not logging of unchanged toast columns would be a problem for row filtering. Am I missing something? Thank you, Rahila Syed
