[HACKERS] Re: How to reproduce serialization failure for a read only transaction.

Regarding this: >> So what does this have to do with relying on the results of read-only transactions that abort? Well, what if you had instead had R ROLLBACK instead of COMMIT -- maybe because you expected ROLLBACK and COMMIT to be equivalent for transactions that don't modify the database, or

[HACKERS] Re: How to reproduce serialization failure for a read only transaction.

This worked for me - thank you so much! The SELECT did fail. Also I cannot reproduce a scenario when "applications must not depend on results read during a transaction that later aborted;". In this example the SELECT itself has failed. Can you show an example where a SELECT completes, but the COMM

[HACKERS] Re: How to reproduce serialization failure for a read only transaction.

Hi Florian, can you explain why do you state that "default isolation level is assumed to be serializable, of course", when you explicitly specify isolation level for every session - why should he default matter at all? When I am trying to reproduce the scenario which you have posted, I am observi

[HACKERS] How to reproduce serialization failure for a read only transaction.

If two transactions both read and write, I can easily reproduce the following: "could not serialize access due to read/write dependencies among transactions". However, the 9.3 documentation says that "When relying on Serializable transactions to prevent anomalies, it is important that any data read

Re: [HACKERS] Let us fix the documentation

Oops, did not notice that - thank you! -- View this message in context: http://postgresql.1045698.n5.nabble.com/Let-us-fix-the-documentation-tp5782999p5783002.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@pos

[HACKERS] Let us fix the documentation

The following url seems to be slightly incorrect: http://www.postgresql.org/docs/9.3/static/sql-prepare.html PREPARE usrrptplan (int) AS SELECT * FROM users u, logs l WHERE u.usrid=$1 AND u.usrid=l.usrid AND l.date = $2; EXECUTE usrrptplan(1, current_date); I guess the first line of the

Re: [HACKERS] Should we improve documentation on isolation levels?

I concur - the documentation is not incorrect, it is just incomplete. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Should-we-improve-documentation-on-isolation-levels-tp5780629p5780636.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. --

[HACKERS] Should we improve documentation on isolation levels?

I am not sure if i am posting in the right place - correct me if I am wrong. The following is not precise: 13.2.1. Read Committed Isolation Level "Also note that two successive SELECT commands can see different data, even though they are within a single transaction, if other transactions commit c

Re: [HACKERS] why semicolon after begin is not allowed in postgresql?

Kevin, I do see your logic now, but this thing is a common mistake - it means that this seems counter-intuitive to some people. What would happen if we applied Occam's razor and just removed this rule? All existing code would continue to work as is, and we would have one less rule to memorize. Th

Re: [HACKERS] Why is UPDATE with column-list syntax not implemented

Claudio, Unfortunately, this UPDATE...FROM approach does not detect ambiguities, unless we go for tricks. -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-is-UPDATE-with-column-list-syntax-not-implemented-tp5779600p5780215.html Sent from the PostgreSQL - hackers mai

[HACKERS] why semicolon after begin is not allowed in postgresql?

I am reading the following in the documentation: "Tip: A common mistake is to write a semicolon immediately after BEGIN. This is incorrect and will result in a syntax error." So, "common mistake" means semicolons after BEGIN seem consistent to many people - it seems consistent to me as well. If Po

Re: [HACKERS] Why is UPDATE with column-list syntax not implemented

Thank you, Tom! -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-is-UPDATE-with-column-list-syntax-not-implemented-tp5779600p5779899.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hackers mailing list (pgsql-hackers@p

Re: [HACKERS] Why is UPDATE with column-list syntax not implemented

Claudio, Can you elaborate how rules can help? -- View this message in context: http://postgresql.1045698.n5.nabble.com/Why-is-UPDATE-with-column-list-syntax-not-implemented-tp5779600p5779896.html Sent from the PostgreSQL - hackers mailing list archive at Nabble.com. -- Sent via pgsql-hacke

[HACKERS] Why is UPDATE with column-list syntax not implemented

9.3 documentation says: According to the standard, the column-list syntax should allow a list of columns to be assigned from a single row-valued expression, such as a sub-select: UPDATE accounts SET (contact_last_name, contact_first_name) = (SELECT last_name, first_name FROM salesmen WHE