On Fri, Jul 23, 2021 at 8:29 AM Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Thu, Jul 22, 2021 at 8:06 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > On Thu, Jul 22, 2021 at 5:15 PM Amit Kapila <amit.kapila16@gmail.com> wrote: > > > > > > On Tue, Jul 20, 2021 at 4:33 PM Dilip Kumar <dilipbalaut@gmail.com> wrote: > > > > > > > > On Tue, Jul 20, 2021 at 3:43 PM Tomas Vondra > > > > <tomas.vondra@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?
