Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key

On Sat, Feb 3, 2018 at 4:04 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Jan 26, 2018 at 1:28 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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