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

Re: "serializable" in comments and names

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: Dan Ports <drkp(at)csail(dot)mit(dot)edu>, "<pgsql-hackers(at)postgresql(dot)org>" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: "serializable" in comments and names
Date: 2010-09-02 17:55:31
Message-ID: AANLkTimL4PgCQRXc3iP4FjGXOtGN1Bp_T3usmYUcrEV5@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Thu, Sep 2, 2010 at 11:41 AM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
>> How about IsXactIsoLevelSnapshot?  Just to be a bit shorter.
>
> I need two macros -- one which has the same definition as the
> current IsXactIsoLevelSerializable, to be used everywhere the old
> macro name currently is used, which conveys that it is an isolation
> level which is based on a transaction snapshot rather than statement
> snapshots (i.e., REPEATABLE READ or SERIALIZABLE) and a new macro
> (which I was planning to call IsXactIsoLevelFullySerializable) which
> conveys that it is the SERIALIZABLE isolation level.  Do you feel
> that IsXactIsoLevelSnapshot works with
> IsXactIsoLevelFullySerializable to convey the right semantics?  If
> not, what would you suggest?

OK, I see what you were going for.  The current definition is:

#define IsXactIsoLevelSerializable (XactIsoLevel >= XACT_REPEATABLE_READ)

...which is certainly a bit odd, since you'd think it would be
comparing against XACT_SERIALIZABLE given the name.

IsXactIsoLevelRepeatableRead()?

XactUsesPerXactSnapshot()?

Or, inverting the sense of it, XactUsesPerStatementSnapshot()?

Just brainstorming...

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company

In response to

Responses

pgsql-hackers by date

Next:From: Kevin GrittnerDate: 2010-09-02 18:23:37
Subject: Re: "serializable" in comments and names
Previous:From: Kevin GrittnerDate: 2010-09-02 17:36:36
Subject: Re: installcheck-world failure

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