Re: [HACKERS] Large Objects versus transactional behavior
hi, On Sat, Apr 30, 2011 at 2:58 PM, Kevin Grittner kevin.gritt...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Large Objects versus transactional behavior
YAMAMOTO Takashi wrote: is there any chance to just make large objects obey the normal semantics in future? I sure hope so, but I have no idea how hard that is. I feel the same about TRUNCATE TABLE now that I recognize the semantic difference between it and DELETE FROM with no WHERE clause. For this release, though, I don't think it would be sane to try to make them comply with transactional semantics. And, as I mentioned, Serializable Snapshot Isolation can only make serializable that which is conforming to the semantics of snapshot isolation. -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Large Objects versus transactional behavior
On Sat, Apr 30, 2011 at 2:58 PM, Kevin Grittner kevin.gritt...@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. 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Large Objects versus transactional behavior
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? -Kevin -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
