What does SET TRANSACTION configure, and when must you issue it?

## A statement that configures, not one that acts Most SQL statements read or change data. `SET TRANSACTION` does neither: it declares how the transaction it applies to should behave. The standard calls these *transaction characteristics*, and the two that matter in practice are: - **Isolation level** — `SET TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }`. What each level actually promises about concurrent transactions is a large subject in its own right; the language part is simply that these four names are the standard's spellings and this is the statement that selects one. - **Access mode** — `SET TRANSACTION READ ONLY` or `SET TRANSACTION READ WRITE`. Both can be given at once, comma-separated: `SET TRANSACTION ISOLATION LEVEL REPEATABLE READ, READ ONLY;`. ## The placement rule The characteristic has to be fixed before the transaction begins doing anything, because the engine needs it in place when the first statement takes its view of the data. So: ```sql START TRANSACTION; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; -- fine: nothing has run yet SELECT count(*) FROM orders; COMMIT; ``` but: ```sql START TRANSACTION; SELECT count(*) FROM orders; SET TRANSACTION ISOLATION LEVEL SERIALIZABLE; -- ERROR on PostgreSQL ``` PostgreSQL rejects the second form outright, telling you `SET TRANSACTION ISOLATION LEVEL` must be called before any query. There is also a wrinkle in what the statement applies to: the SQL standard frames `SET TRANSACTION` as configuring the *next* transaction, while engines such as PostgreSQL apply it to the current one provided it has not started work. Both readings put the statement in the same place in your script, which is why the difference rarely bites — write it immediately after opening the transaction and you are correct either way. ## The inline form is usually better Every characteristic `SET TRANSACTION` accepts can also be attached to the statement that opens the transaction: ```sql START TRANSACTION ISOLATION LEVEL SERIALIZABLE, READ ONLY; ``` This is one statement instead of two, and it makes the placement rule unbreakable — you cannot accidentally put the configuration after a query. Prefer it in application code; keep the standalone `SET TRANSACTION` for interactive sessions and scripts where the opening statement is generated elsewhere. ## What READ ONLY actually does `READ ONLY` is an assertion the engine enforces. Inside a read-only transaction, `SELECT` works normally, but `INSERT`, `UPDATE` and `DELETE` against non-temporary tables, and DDL that changes persistent objects, are rejected with an error at the moment you issue them. It is not a performance hint and not a lock strategy — treat it as a cheap, declarative guard. Typical uses: a reporting or BI connection that must never write, a script that dumps data, a code path you want to prove is side-effect free. Marking such sessions read-only turns "this analytics query accidentally had an UPDATE pasted into it" from an incident into an error message. Some engines can also use the declaration internally to skip work they only need for writers, but the guarantee you should rely on is the enforcement. ## Setting a default for the session Setting characteristics per transaction is explicit but repetitive. Engines expose a session-level default so every subsequent transaction inherits it; PostgreSQL's spelling is `SET SESSION CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL REPEATABLE READ;`, and other engines have their own. Because the spelling varies, application code usually sets this through the connection pool or driver configuration instead of emitting SQL by hand, and reserves the per-transaction statement for the handful of transactions that genuinely need something different from the default. ## What interviewers are checking Three things. That you know `SET TRANSACTION` configures characteristics rather than doing work. That you know the placement rule and can say what happens if you break it. And that you know `READ ONLY` is enforced, not advisory. Being able to add "I usually put the characteristics on `START TRANSACTION` so placement can't go wrong" is the detail that reads as having actually used it.