Re: Large Objects versus transactional behavior - Mailing list pgsql-hackers

From yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
Subject Re: Large Objects versus transactional behavior
Date
Msg-id 20110513004829.A12BB14A224@mail.netbsd.org
Whole thread Raw
In response to Re: Large Objects versus transactional behavior  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
hi,

> On Sat, Apr 30, 2011 at 2:58 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.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.

as a novice user who has been annoyed by them, i'm curious about
the rationale of the unusual semantics.
is there any chance to "just" make large objects obey the normal semantics
in future?

YAMAMOTO Takashi


pgsql-hackers by date:

Previous
From: Martin Belleau
Date:
Subject: windows installer (similar to old EnterpriseDB installer)
Next
From: Magnus Hagander
Date:
Subject: Re: Unfriendly handling of pg_hba SSL options with SSL off