Skip site navigation (1) Skip section navigation (2)

Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid

From: Simon Riggs <simon(at)2ndQuadrant(dot)com>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, Boxuan Zhai <bxzhai2010(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Date: 2011-01-03 09:37:56
Message-ID: 1294047476.2090.7924.camel@ebony (view raw, whole thread or download thread mbox)
Lists: 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
with suggested resolutions for this release here

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 
 PostgreSQL Development, 24x7 Support, Training and Services

In response to


pgsql-hackers by date

Next:From: Magnus HaganderDate: 2011-01-03 09:44:19
Subject: Re: Visual Studio 2010/Windows SDK 7.1 support
Previous:From: Joel JacobsonDate: 2011-01-03 09:15:34
Subject: Re: contrib/snapshot

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group