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

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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Robert Haas" <robertmhaas(at)gmail(dot)com>
Cc: "Greg Smith" <greg(at)2ndquadrant(dot)com>, "Simon Riggs" <simon(at)2ndquadrant(dot)com>, "Marko Tiikkaja" <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "Boxuan Zhai" <bxzhai2010(at)gmail(dot)com>, <pgsql-hackers(at)postgresql(dot)org>, "Stephen Frost" <sfrost(at)snowman(dot)net>
Subject: Re: Re: new patch of MERGE (merge_204) & a question about duplicated ctid
Date: 2011-01-03 19:01:20
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> Before you decide to taunt me again, I guess I should point out a
>> few things here.
> Sorry, that was intended as good-natured humor, not taunting.
Oh, I took it that way.  I guess my attempt at humor through an
oblique reference to a line from "Monty Python and the Holy Grail"
fell flat.  :-/  I guess I should have said "before you taunt me a
second time" to make it more readily recognizable...
> I think that the work you are doing on the serializability stuff
> is *exactly* the right fix for the concurrency issues associated
> with MERGE.
It's got a nice consistency with current behavior, with reads never
blocking or being blocked, but I can see why people would want a
MERGE which could dance around the concurrency problems and always
succeed with UPSERT behavior.
Various topics have come up which seem like they might benefit from
predicate locking.  I don't know how many would need locks which
introduce blocking.  I think it will actually be very easy to adapt
the predicate locking for such things as transactional cache
invalidation (which is what drew the interest of the MIT folks). 
I'm not sure how much work it would be to adapt it to use for the
type of blocking locks which seem to be needed based on some of the
MERGE discussions I've read.  It think it will be non-trivial but

In response to


pgsql-hackers by date

Next:From: Robert HaasDate: 2011-01-03 19:01:36
Subject: Re: pg_dump --split patch
Previous:From: Magnus HaganderDate: 2011-01-03 18:58:19
Subject: Re: back branches vs. VS 2008

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