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

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

From: Greg Smith <greg(at)2ndquadrant(dot)com>
To: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
Cc: 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 06:53:58
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Marko Tiikkaja wrote:
> I'm confused.  Are you saying that the patch is supposed to lock the 
> table against concurrent INSERT/UPDATE/DELETE/MERGE?  Because I don't 
> see it in the patch, and the symptoms you're having are a clear 
> indication of the fact that it's not happening.  I also seem to recall 
> that people thought locking the table would be excessive.

That's exactly what it should be doing.  I thought I'd seen just that in 
one of the versions of this patch, but maybe that's a mistaken memory on 
my part.  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.  In 
earlier versions, I think this code was running into issues before it 
even got to there.  If you're right that things like the duplicate key 
error in the current version are caused exclusively by not locking 
enough, that may be the next necessary step here.

Greg Smith   2ndQuadrant US    greg(at)2ndQuadrant(dot)com   Baltimore, MD
PostgreSQL Training, Services and Support
"PostgreSQL 9.0 High Performance":

In response to


pgsql-hackers by date

Next:From: Brar PieningDate: 2011-01-03 07:19:29
Subject: Visual Studio 2010/Windows SDK 7.1 support
Previous:From: Hannu KrosingDate: 2011-01-03 01:30:12
Subject: Re: Sync Rep Design

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