PostgreSQL事务锁

Question

I'm using pg, pg-native for my project, I use transaction something like below code, I'm not familiar with database,
https://github.com/brianc/node-postgres/wiki/Transactions
1. Does this lock table or only lock the row?
2. The lock does it means diable Create , Update , Delete in CRUD . but still can be Read ? if so, the data be select, is it the data before this change (before BEGIN )?

"pg": "^4.5.1", "pg-native": "^1.10.0",

var pg = require('pg').native;
...

var rollback = function(dbClient, response) {
  dbClient.query('ROLLBACK', function() {
    dbClient.end();
    // reject(response);
  });
};

dbClient.query('BEGIN', function(error, result) {
  ...

dbClient.query('COMMIT', dbClient.end.bind(dbClient));
  ...

Answer 1

Read the documentation for the complete picture. It is worth the effort.

PostgreSQL has different levels of locking: table locks and row locks (I won't go into advisory loks).

Table locks can be taken explicitly with the LOCK command, but that's something you don't do normally. The normal case are implicit table locks that are taken when you access a table – for example, when you read or write data in a table, a lock will be taken that prevents concurrent users from ALTER or DROP on the table.

Row locks are taken by DML statements ( INSERT , UPDATE and DELETE ) as well as by SELECT ... FOR SHARE/UPDATE . They prevent concurrent modification of the locked row.

All locks are released at the end of a transaction. If you didn't explicitly start a transaction, each statement runs in its own transaction, and locks won't outlast the duration of the single statement. If you start a transaction explicitly with BEGIN or START TRANSACTION , it lasts until you COMMIT or ROLLBACK .

One important design concept of PostgreSQL (and any other database that uses multiversion concurrency control ) is that readers never block writers and vice versa. This is facilitated by keeping old versions of the data around, and readers are served with data that are valid at their snapshot (roughly, the consistent view of the database valid at statement or transaction start). These old rows are eventually cleaned up by the autovacuum background process.