Can concurrent value modification impact single select in PostgreSQL 9.1?

Question

Consider the following query executed in PostgreSQL 9.1 (or 9.2):

SELECT * FROM foo WHERE bar = true

Suppose it's a fairly long running query (e.g. taking a minute).

If at the start of the query there are 5 million records for which bar = true holds, and during this query in another transaction there are rows added and removed in the foo table, and for some existing rows updates are made to the bar field.

Will any of this affect the outcome of the above shown select query?

I know about transaction-isolation and visibility between separate statements in a single transaction, but what about a single statement that's running?

Answer 1

No.
Due to the MVCC model only tuples that are visible at query start will be used in a single SELECT. Details in the manual here:

Read Committed is the default isolation level in PostgreSQL. When a transaction uses this isolation level, a SELECT query (without a FOR UPDATE/SHARE clause) sees only data committed before the query began; it never sees either uncommitted data or changes committed during query execution by concurrent transactions. In effect, a SELECT query sees a snapshot of the database as of the instant the query begins to run. However, SELECT does see the effects of previous updates executed within its own transaction, even though they are not yet committed. Also note that two successive SELECT commands can see different data, even though they are within a single transaction, if other transactions commit changes during execution of the first SELECT.

Emphasis mine.

Answer 2

The query will be a read-consistent view of the data as of the start of the query. In Postgresql, the documentation on Multi-Version Concurrency Control (MVCC) explains how it is done (multiple versions of a record exist in the table). In Oracle, the Sequence Change Number (SCN) is used along with "before-images" of modified data. Here is an old doc, Transaction Processing in Postgresql, with the section "non-overwriting storage management". But take a look at MVCC.

Or read the chapter on MVCC in the Postgresql doc