Re: [BUGS] Status of issue 4593

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Gregory Stark" <stark(at)enterprisedb(dot)com>
Cc: "Josh Berkus" <josh(at)agliodbs(dot)com>, "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Peter Eisentraut" <peter_e(at)gmx(dot)net>, "Jeff Davis" <pgsql(at)j-davis(dot)com>, "Lee McKeeman" <lmckeeman(at)opushealthcare(dot)com>, "PG Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: [BUGS] Status of issue 4593
Date: 2009-01-13 19:03:16
Message-ID: 496C9114.EE98.0025.0@wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

>>> Gregory Stark <stark(at)enterprisedb(dot)com> wrote:
> "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov> writes:
>> In what way would an application want to treat deadlocks and update
>> conflicts differently? Both result from conflicts with concurrent
>> transactions and can be retried automatically. It seems like an
>> implementation detail with little chance of impact on applications
to
>> me. Can anyone provide a contrary example or argument?
>
> Well generally deadlocks are treated differently in that they are
treated by
> rewriting the application to not cause deadlocks.

I certainly don't propose changing the PostgreSQL error number or the
content of what is logged. Just the SQLSTATE. How would that make
what you suggest harder? It would certainly allow applications and
frameworks which are SQLSTATE-aware to automatically recover from
these until the rewrite is complete, which can hardly be considered a
bad thing.

-Kevin

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Merlin Moncure 2009-01-13 19:39:11 problem with non-greedy regex match
Previous Message Gregory Stark 2009-01-13 18:59:49 Re: [BUGS] Status of issue 4593

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-01-13 19:07:05 Re: Hot standby and b-tree killed items
Previous Message Simon Riggs 2009-01-13 19:03:15 Re: Time to finalize patches for 8.4 beta