New answers tagged

3

You don't need to do anything to get statement level consistency A query always sees a consistent state of the database regardless of the isolation level you use. Quote from the manual: This means that each SQL statement sees a snapshot of data (a database version) as it was some time ago, regardless of the current state of the underlying data. ...


2

Read committed (especially section 13.2.1) is the default read level in PostgreSQL. This read level will give you a snapshot of what has been committed before your transaction starts. It will allow other transactions to read and write to your table, you just won't be able to see any writes made after the start of your transaction. Does this only apply ...


4

This is how Postgres was designed from ground up (as opposed to SQL Server where this was added very late) See the manual for details: http://www.postgresql.org/docs/current/static/mvcc-intro.html You can't actually configure Postgres so that readers would block writers (automatically or implicitly) The only way to block read access in Postgres is to ...


8

Your query is reporting the session-level setting of transaction isolation level, which is set to serializable. Using a NOLOCK hint (or its synonym READUNCOMMITTED) overrides the session isolation level for access to the specific object (table in this case) the hint is specified against. So, the transaction is still running under serializable isolation, ...


8

Lock hints are orthogonal to isolation level. While they address similar concerns, adding a lock hint does not change the isolation level. Your transaction will still be a 'serializable' transaction. Of course, the lock hint make the query operation itself violate the transaction serializability, but you are looking at a property of the transaction.



Top 50 recent answers are included