From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | amul sul <sulamul(at)gmail(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] Restrict concurrent update/delete with UPDATE of partition key |
Date: | 2017-11-24 15:28:15 |
Message-ID: | CA+TgmoYsMRo2PHFTGUFifv4ZSCZ9LNJASbOyb=9it2=UA4j4vw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Nov 23, 2017 at 6:48 AM, amul sul <sulamul(at)gmail(dot)com> wrote:
> And remaining are EvalPlanQualFetch, ExecOnConflictUpdate,
> RelationFindReplTupleByIndex & RelationFindReplTupleSeq. Note that check in
> RelationFindReplTupleByIndex & RelationFindReplTupleSeq will have LOG not an
> ERROR.
The first one is going to come up when you have, for example, two
concurrent updates targeting the same row, and the second one when you
have an ON CONFLICT UPDATE clause. I guess the latter two are
probably related to logical replication, and maybe not easy to test
via an automated regression test.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitry Shalashov | 2017-11-24 15:44:21 | Re: Query became very slow after 9.6 -> 10 upgrade |
Previous Message | Erikjan Rijkers | 2017-11-24 15:08:08 | Re: Add RANGE with values and exclusions clauses to the Window Functions |