Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
От | Simon Riggs |
---|---|
Тема | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid |
Дата | |
Msg-id | 1294047476.2090.7924.camel@ebony обсуждение исходный текст |
Ответ на | Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid (Greg Smith <greg@2ndquadrant.com>) |
Ответы |
Re: Re: new patch of MERGE (merge_204) & a question about
duplicated ctid
|
Список | pgsql-hackers |
On Mon, 2011-01-03 at 01:53 -0500, Greg Smith wrote: > In advance of the planned but not available yet ability to > lock individual index key values, locking the whole table is the only > possible implementation that can work correctly here I'm aware of. This was discussed here http://archives.postgresql.org/pgsql-hackers/2010-10/msg01903.php with suggested resolutions for this release here http://archives.postgresql.org/pgsql-hackers/2010-10/msg01907.php In summary, that means we can either 1. Lock the table for ShareRowExclusiveLock 2. throw a SERIALIZABLE error, if we come up against a row that cannot be neither MATCHED nor NON MATCHED. 3. Bounce the patch to 9.2, commit early and then work on a full concurrency solution before commit. The solution strawman is something like EvalPlanQual with a new snapshot for each re-checked row, emulating the pattern of snapshots/rechecks that would happen in a PL/pgSQL version of an UPSERT. Either way, we're saying that MERGE will not support concurrent operations safely, in this release. Given the continued lack of test cases for this patch, and the possible embarrassment over not doing concurrent actions, do we think (3) is the right road? -- Simon Riggs http://www.2ndQuadrant.com/books/PostgreSQL Development, 24x7 Support, Training and Services
В списке pgsql-hackers по дате отправления: