On Sat, Feb 3, 2018 at 4:04 AM, Robert Haas <robertmh...@gmail.com> wrote: > On Fri, Jan 26, 2018 at 1:28 AM, Amit Kapila <amit.kapil...@gmail.com> wrote: >> So, this means that in case of logical replication, it won't generate >> the error this patch is trying to introduce. I think if we want to >> handle this we need some changes in WAL and logical decoding as well. >> >> Robert, others, what do you think? I am not very comfortable leaving >> this unaddressed, if we don't want to do anything about it, at least >> we should document it. > > As I said on the other thread, I'm not sure how reasonable it really > is to try to do anything about this. For both the issue you raised > there, I think we'd need to introduce a new WAL record type that > represents a delete from one table and an insert to another that > should be considered as a single operation. >
I think to solve the issue in this thread, a flag should be sufficient that can be used in logical replication InvalidBlockNumber in CTID for Deletes. > I'm not keen on that idea, > but you can make an argument that it's the Right Thing To Do. I would > be more inclined, at least for v11, to just document that the > delete+insert will be replayed separately on replicas. > Even if we do what you are suggesting, we need something in WAL (probably a flag to indicate this special type of Delete), otherwise, wal consistency checker will fail. Another idea would be to mask the ctid change so that wal consistency checker doesn't cry. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
