Re: serialization errors

From: Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Greg Copeland <greg(at)CopelandConsulting(dot)Net>, Ryan VanderBijl <rvbijl-pgsql(at)vanderbijlfamily(dot)com>, PostgresSQL General Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: serialization errors
Date: 2003-01-31 16:50:38
Message-ID: 20030131084513.E45631-100000@megazone23.bigpanda.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Fri, 31 Jan 2003, Tom Lane wrote:

> Stephan Szabo <sszabo(at)megazone23(dot)bigpanda(dot)com> writes:
> > The problem with this is that it's probably pretty unimplementable,
>
> Yeah. This shows the difference between what we do and true
> serialization. An academic would tell you that true serialization
> requires predicate locking --- that is, as soon as transaction T1 has
> done a "SELECT ... WHERE foo", then concurrent transaction T2 must wait
> for T1 if it tries to insert *or remove* a row that would satisfy foo.

Right, or you need to do some kind of thing where instead of locking, you
keep track of what predicate violations have occurred and prevent cycles
by killing a transaction in the cycle with a serialization error
(basically the optimistic locking version of the above I'd guess). The
enforcement would be a nightmare in any case if you wanted perfect results
(no false positives), especially given functions and custom aggregates
where you might have to run the results again after data modifications and
see if they've changed since all you get is a black box.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Gregory Wood 2003-01-31 17:12:18 Re: [PERFORM] One large v. many small
Previous Message Greg Copeland 2003-01-31 16:24:39 Re: serialization errors