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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: amul sul <sulamul(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key
Date: 2018-02-02 22:34:46
Message-ID: CA+TgmoY_h+3J46zShEZD0_KLRHa1NsJkGrC4Ou=Bqt=KRboHtg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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'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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Claudio Freire 2018-02-02 22:52:02 Re: [HACKERS] Vacuum: allow usage of more than 1GB of work mem
Previous Message Robert Haas 2018-02-02 22:17:30 Re: Boolean partitions syntax