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

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: (view raw, whole thread or download thread mbox)
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

pgsql-general by date

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

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