Re: Serializable access giving wrong error messages?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: Mikko Vierula <mikko(dot)vierula(at)elektroniikkatyo(dot)fi>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Serializable access giving wrong error messages?
Date: 2001-12-28 00:21:40
Message-ID: 27199.1009498900@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> In Mikko's both examples, Transaction 1 has to see a tuple
> which didn't exist at the beginning of the transaction
> while checking duplicate error.

I'm not sure about that. What if the "tuple that didn't exist" is
an updated version of a row that did exist earlier --- that is, the
conflicting operation is an update not an insert? Does your answer
change depending on whether the update changed the row's key value?

In the most straightforward implementation of your suggestion, I believe
that a concurrent update (on a non-key column) would result in the
system randomly delivering either "duplicate key" or "serialization
error" depending on whether the index processing happened to look at
the older or newer other tuple first. That definitely does not strike
me as an improvement over the current behavior.

In any case, I still think that this'd be trading a useful error message
(ie, one that tells you what is wrong) for a uselessly non-specific one.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Hiroshi Inoue 2001-12-28 01:32:43 Re: Serializable access giving wrong error messages?
Previous Message Hiroshi Inoue 2001-12-27 23:54:05 Re: Serializable access giving wrong error messages?