Question

I’m building a background job that’s updating users’ statistics for a web application. The job currently takes 55-60 seconds, and I’m concerned about what would happen if a user were to try to load his stats page at the same time that job is running.

From what I’ve read about PostgreSQL and concurrency, if two clients attempt to access the same row (one updating and one reading), and I’m not explicitly starting any transactions, the first one just has to wait for the second one to finish.

So if I’m understanding that correctly, the only performance hit I’m likely to incur is on the infinitesimally small chance that a user tries to load his stats page at the same moment that the row is being updated. It’s not like the whole stats table is locked up during the 55-60 second job unless I were to explicitly configure Postgres to do that, right?

Is that a correct interpretation? Are there other factors I’m missing?

(I mention the Rails part just in case it has any bearing on the above scenario)

(Also: the PostgreSQL version is 9.0.4)

Answer 1

It depends on transaction isolation level. If I’ve got your case – you are talking about Dirty Read avoiding delay. And YES, Dirty Read is impossible if you are using default isolation level. Reader will wait for the writer only when it will try to get the same row that is being updated.

Read Committed is the default isolation level in PostgreSQL. When a transaction runs on this isolation level, a SELECT query sees only data committed before the query began;

specs on ISOLATION