Sample questions
Pg OperationsDifficulty 1
In psql, \dt lists tables and \d orders describes a table's columns and indexes. Why can't these two commands be used inside a Go application's SQL query string sent over the wire to PostgreSQL?
- aBecause
\dt/\d are psql-only meta-commands, expanded client-side, not SQL the server parses✓ - bBecause the server only accepts SQL from the postgres superuser account, never from an application role
- cBecause
\dt and \d require a superuser session and application roles cannot open one - dBecause these commands only exist in PostgreSQL 18 and are unavailable to client libraries such as pgx
Explanation:Commands starting with a backslash are psql-specific meta-commands, interpreted and expanded by the psql client itself before anything is sent to the server; the server's SQL parser has no notion of \dt or \d. An application driver like pgx only ever sends SQL text, so it must query the catalog directly (e.g. information_schema or pg_catalog) instead.
Pg OperationsDifficulty 1
Running \l inside psql prints a table with columns like Name, Owner, Encoding. What does this meta-command actually enumerate?
- aThe tables that exist inside the currently connected database
- bThe databases that exist on the connected PostgreSQL server/cluster✓
- cThe extensions that are currently installed in the connected database
- dThe open client connections currently attached to the server
Explanation:\l (list) queries the server for every database in the cluster it's currently connected to, along with owner, encoding and access privileges — it has nothing to do with tables inside one database (that's \dt), installed extensions (\dx), or active connections (pg_stat_activity).
Pg OperationsDifficulty 1
\du in psql prints a List of roles table with a Role name and Attributes column (e.g. Superuser, Create role). What is this command showing?
- aThe users currently logged into the database via active TCP connections
- bThe tables the current user has been granted access to
- cThe roles defined on the server and the privileges/attributes each one carries✓
- dThe schemas that exist in the current database and their owners
Explanation:\du lists every role in the cluster together with its attributes (superuser, can create roles, can create databases, login capability, and so on). Active connections come from pg_stat_activity, granted table access comes from \dp/information_schema, and schemas come from \dn.
Pg OperationsDifficulty 1
After typing \timing once in a psql session and then running a query, psql prints an extra line such as Time: 0.075 ms under the result. What does entering \timing a second time do?
- aIt resets the timer so the next query's time is measured from zero milliseconds
- bIt switches psql to show cumulative time across the whole session instead of per query
- cIt makes PostgreSQL log the query's execution time into the server log file
- dIt toggles the feature off, so subsequent query results no longer print a
Time: line✓
Explanation:\timing is a toggle: each time you type it, psql flips between showing and not showing the elapsed wall-clock time after each statement, printed client-side in the psql session — it doesn't touch the server log or reset any counter.
Pg OperationsDifficulty 1
A junior developer notices that opening 200 simultaneous connections to PostgreSQL makes the server host's process list (ps aux) grow by roughly 200 entries. Why?
- aPostgreSQL uses a process-per-connection model: the postmaster forks a dedicated backend OS process for each client connection✓
- bPostgreSQL spawns one thread per connection inside a single shared process, and
ps aux mistakenly lists threads as processes - cEach connection triggers PostgreSQL to start a background autovacuum worker dedicated to that session
- dThis only happens when
max_connections is left at its default value and disappears once it is raised
Explanation:PostgreSQL's classic architecture forks one full OS backend process per client connection (not a thread), which is why connection count shows up directly in the process list — and why connections aren't free: each carries real memory and OS scheduling overhead.
Pg OperationsDifficulty 1
SHOW statement_timeout;
-- statement_timeout
-- -------------------
-- 0
SET statement_timeout = '2s';
SHOW statement_timeout;
-- statement_timeout
-- -------------------
-- 2s
After this session disconnects and a new session connects, what will
SHOW statement_timeout; report?
- a
2s, because SET without LOCAL persists the value for all future connections - b
0 (or whatever the server-wide default is), because SET only changes the value for the current session✓ - cAn error, because
statement_timeout cannot be changed with SET, only via ALTER SYSTEM - d
2s, because PostgreSQL stores session-level SET values in the database's system catalog
Explanation:Plain SET changes a run-time parameter only for the lifetime of the current session (or until reset); it never persists across a new connection. Making a value stick for all future sessions requires ALTER SYSTEM, ALTER DATABASE ... SET, or a change in postgresql.conf — none of which happen here.