Re: Large Objects versus transactional behavior

Поиск
Список
Период
Сортировка
От yamt@mwd.biglobe.ne.jp (YAMAMOTO Takashi)
Тема Re: Large Objects versus transactional behavior
Дата
Msg-id 20110513004829.A12BB14A224@mail.netbsd.org
обсуждение исходный текст
Ответ на Re: Large Objects versus transactional behavior  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Martin Belleau
Дата:
Сообщение: windows installer (similar to old EnterpriseDB installer)
Следующее
От: Magnus Hagander
Дата:
Сообщение: Re: Unfriendly handling of pg_hba SSL options with SSL off