From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Large Objects versus transactional behavior |
Date: | 2011-05-07 02:03:36 |
Message-ID: | BANLkTikyojV13rDOGfFsryg6WUUvZEBbMA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Apr 30, 2011 at 2:58 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> This is related to the "SIREAD lock versus ACCESS EXCLUSIVE lock"
> thread, but seemed different enough to merit spinning off a new
> thread.
>
> Our shop hasn't used large objects so far because of the lack of
> security (until 9.1), so I never noticed the rather unusual
> transactional semantics of large objects. From the devel
> documentation:
>
> http://developer.postgresql.org/pgdocs/postgres/lo-interfaces.html#LO-OPEN
>
> | [...] with INV_READ you cannot write on the descriptor, and the
> | data read from it will reflect the contents of the large object at
> | the time of the transaction snapshot that was active when lo_open
> | was executed, regardless of later writes by this or other
> | transactions. Reading from a descriptor opened with INV_WRITE
> | returns data that reflects all writes of other committed
> | transactions as well as writes of the current transaction. This is
> | similar to the behavior of REPEATABLE READ versus READ COMMITTED
> | transaction modes for ordinary SQL SELECT commands.
>
> Since Serializable Snapshot Isolation can only serialize behavior
> which is working within the semantics of snapshot isolation, it
> doesn't seem like SSI has any chance of serializing access to the
> contents of a large object while the current behavior stands.
> Modifications to the *references* to large objects within the bodies
> of normal tables is properly tracked by SSI, but no predicate locks
> are taken on the large object contents themselves, nor would
> modifications to the contents be able to generate a rw-conflict
> between transactions.
>
> In other words, I don't think there is any action item here for SSI
> in terms of C code for 9.1, but we may want to mention the unusual
> transaction-related behavior of large objects within the Concurrency
> Control chapter of the docs.
>
> Comments?
Well, in the long run, I think serializability ought to apply to large
objects along with everything else. But documenting it seems like a
reasonable approach for now.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-05-07 02:25:09 | Re: switch UNLOGGED to LOGGED |
Previous Message | Robert Haas | 2011-05-07 02:02:13 | Re: a bit more precise MaxOffsetNumber |