Re: Concurrent MERGE - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: Concurrent MERGE
Date
Msg-id 4C5ACB9C020000250003428C@gw.wicourts.gov
Whole thread Raw
In response to Re: Concurrent MERGE  (Josh Berkus <josh@agliodbs.com>)
Responses Re: Concurrent MERGE
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> wrote:
> Well, we *still* want predicate locking regardless of what MERGE
> supports.  It's useful in about 9 different ways.
I don't know whether this is the right time to discuss those 9
different uses, but just so everyone knows, the SIRead locks needed
for the SSI implementation in the current serializable  patch have
some characteristics which may be exactly what you want (if you want
cache invalidation or some such) or may render them totally useless
from some purposes.
(1) They don't block anything.  Ever.  Conflicts with writes are
detected, and right now that is used to mark rw-conflicts between
serializable transactions.  I assume we may want to add listeners
who can be signaled on such conflicts, too; but that isn't there
now.
(2) They are only acquired by serializable transactions.
(3) They can survive the transaction which acquired them, and even
the termination of the process which ran the transaction.  Right now
they go away when the last serializable transaction which overlapped
the acquiring serializable transaction completes.  If we add
listeners, I assume we'd want to keep them as long as a listener was
registered, probably with some timeout feature.
Just so everyone knows what is and isn't there right now.
-Kevin


pgsql-hackers by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Drop one-argument string_agg? (was Re: [BUGS] string_agg delimiter having no effect with order by)
Next
From: Josh Berkus
Date:
Subject: Re: Concurrent MERGE