Re: serializable read only deferrable
От | Kevin Grittner |
---|---|
Тема | Re: serializable read only deferrable |
Дата | |
Msg-id | 4CFE80DC02000025000383E9@gw.wicourts.gov обсуждение исходный текст |
Ответ на | Re: serializable read only deferrable (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: serializable read only deferrable
|
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> wrote: > I assume this would have to be a "hard" definition of READ ONLY, > not the rather squishy definition we use now? Oh, I just went through the code on setting READ ONLY and discovered that contrary to the standard *and* the PostgreSQL documentation, you can change the status of a transaction between READ ONLY and READ WRITE at will. Yeah, that's a problem for my intended use. Many optimizations would need to go right out the window, and the false positive rate under SSI would be high. > How would we manage the compatibility implications? Comply with the standard. The bright side of this is that it wouldn't require any change to our user docs. http://www.postgresql.org/docs/current/interactive/sql-start-transaction.html | This command begins a new transaction block. If the isolation | level or read/write mode is specified, the new transaction has | those characteristics, as if SET TRANSACTION was executed. This is | the same as the BEGIN command. and on the same page: | Compatibility | | In the standard, it is not necessary to issue START TRANSACTION to | start a transaction block: any SQL command implicitly begins a | block. PostgreSQL's behavior can be seen as implicitly issuing a | COMMIT after each command that does not follow START TRANSACTION | (or BEGIN), and it is therefore often called "autocommit". Other | relational database systems might offer an autocommit feature as a | convenience. No mention of "and you can change back and forth between READ ONLY and READ WRITE any time during the transaction, including between reads and writes, as many times as you like." Was there a justification for this behavior, or was it just not implemented carefully? Does anyone currently depend on the current behavior? test=# create table asdf (id int not null primary key); NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "asdf_pkey" for table "asdf" CREATE TABLE test=# set default_transaction_isolation = serializable; SET test=# set transaction read only; SET BEGIN test=# set transaction read only; SET test=# select 1;?column? ---------- 1 (1 row) test=# set transaction read write; SET test=# insert into asdf values (1); INSERT 0 1 test=# set transaction read only; SET test=# select * from asdf;id ---- 1 (1 row) test=# set transaction read write; SET test=# insert into asdf values (2); INSERT 0 1 test=# commit; COMMIT I find that to be a huge POLA violation. I will happily prepare a patch to fix this if there is agreement that we want it. I really need READ ONLY *transactions*, not READ ONLY *moments* within transactions to do any optimization based on the property. -Kevin
В списке pgsql-hackers по дате отправления: