Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key
От | Robert Haas |
---|---|
Тема | Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key |
Дата | |
Msg-id | CA+TgmoY_h+3J46zShEZD0_KLRHa1NsJkGrC4Ou=Bqt=KRboHtg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: [HACKERS] Restrict concurrent update/delete with UPDATE ofpartition key
|
Список | pgsql-hackers |
On Fri, Jan 26, 2018 at 1:28 AM, Amit Kapila <amit.kapila16@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'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
В списке pgsql-hackers по дате отправления: