| From: | Jeff Davis <pgsql(at)j-davis(dot)com> |
|---|---|
| To: | Greg Stark <stark(at)enterprisedb(dot)com> |
| Cc: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, "<Markus Wanner" <markus(at)bluegap(dot)ch>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: User-facing aspects of serializable transactions |
| Date: | 2009-06-01 21:26:43 |
| Message-ID: | 1243891603.12209.45.camel@monkey-cat.sm.truviso.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 2009-06-01 at 22:12 +0100, Greg Stark wrote:
> No, I'm not. I'm questioning whether a serializable transaction
> isolation level that makes no guarantee that it won't fire spuriously
> is useful.
I am also concerned (depending on implementation, of course) that
certain situations can make it almost certain that you will get
serialization failures every time. For instance, a change in the heap
order, or data distribution, could mean that your application is unable
to make progress at all.
Is this a valid concern, or are there ways of avoiding this situation?
I would think that we'd need some way to detect that this is happening,
give it a few tries, and then resort to full serialization for a few
transactions so that the application can make progress.
Regards,
Jeff Davis
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Guillaume Smet | 2009-06-01 21:39:08 | Re: Suggested TODO: allow ALTERing of typemods without heap/index rebuild |
| Previous Message | Greg Stark | 2009-06-01 21:17:30 | Re: Suggested TODO: allow ALTERing of typemods without heap/index rebuild |