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

Re: Transaction Snapshot Cloning

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Florian G(dot) Pflug" <fgp(at)phlo(dot)org>
Cc: Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Transaction Snapshot Cloning
Date: 2008-01-16 16:49:28
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
"Florian G. Pflug" <fgp(at)phlo(dot)org> writes:
> I seem to remember there being some pushback to the idea of changing the 
> semantics of "set transaction isolation read only" from "soft" to "hard" 
> semantics though - on the basis that it might break existing 
> applications. If that has changed (or my memory tricks me ;-) ) I'd 
> volunteer to create a patch for 8.4 to make "set transaction read only" 
> a hard constraint.

AFAICT it would violate the SQL spec as well as breaking backward
compatibility.  SQL99 4.32 saith

         An SQL-transaction has an access mode that is either read-only
         or read-write. The access mode may be explicitly set by a <set
         transaction statement> before the start of an SQL-transaction or
         by the use of a <start transaction statement> to start an SQL-
         transaction; otherwise, it is implicitly set to the default access
         mode for the SQL-session before each SQL-transaction begins. If no
         <set session characteristics statement> has set the default access
         mode for the SQL-session, then the default access mode for the SQL-
         session is read-write. The term read-only applies only to viewed
         tables and persistent base tables.

That last sentence is the basis for exempting temp tables from the
read-only restriction.

I'm not sure what the most convenient user API would be for an on-demand
hard-read-only mode, but we can't use SET TRANSACTION READ ONLY for it.
It'd have to be some other syntax.  Maybe just use a GUC variable
instead of bespoke syntax?  SET TRANSACTION is really just syntactic
sugar for GUC SET operations anyway ...

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2008-01-16 16:52:53
Subject: Re: Some ideas about Vacuum
Previous:From: Mischa SandbergDate: 2008-01-16 16:41:42
Subject: postgresql in FreeBSD jails: proposal

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