Re: Serializable implementation

From: Jeff Davis <pgsql(at)j-davis(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Serializable implementation
Date: 2010-01-07 22:44:22
Message-ID: 1262904262.5908.491.camel@monkey-cat.sm.truviso.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, 2010-01-07 at 16:27 -0600, Kevin Grittner wrote:
> Could you draft a proposed doc change? While my ideas have
> sometimes influenced the docs, my words don't tend to make it, so
> I'm probably not the best candidate to suggest something. (That's
> not actually a shocker for me, since I'm a visual thinker, and
> getting ideas into words is a bit slow and clumsy for me.)

Sure. I wonder how many doc-only patches are going to be in the Jan
commitfest? ;)

> I'm torn between thinking it would be good to spell it that way and
> thinking that we should have "serializable_isolation_implementation"
> GUC (or something to that effect) which maps to an enumeration
> containing "snapshot" and "ssi". Opinions welcome, since I've put
> that GUC at the top of my implementation list. :-)

If there are different semantics, we shouldn't just call it an
implementation detail. Particularly when the old behavior violates the
standard (at least the newest version, I think).

> I'd be inclined to
> argue for changing the behavior of SERIALIZABLE in the first release
> where we have true serializable transactions implemented.

Ok, I don't have a strong opinion about that.

> It really depends on application code we might
> break, which is hard to determine.

Well, hopefully it doesn't break anything. Applications asking for
SERIALIZABLE should already be expecting serialization errors. Did you
have something else in mind?

Regards,
Jeff Davis

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2010-01-07 22:45:08 Re: Add .gitignore files to CVS?
Previous Message A.M. 2010-01-07 22:41:41 Re: Testing with concurrent sessions