All quizzesHard
RLS, Partitioning & FDW — Series 3
Preview — 3 of 10 questions
A table has RLS enabled with a strict tenant-isolation policy, but the table's owner role still sees every row when querying it directly. Why, and what fixes it?
ABy default, table owners (and superusers) bypass RLS entirely — the policies simply aren't evaluated for them, the same way a role with BYPASSRLS bypasses it. ALTER TABLE orders FORCE ROW LEVEL SECURITY; changes this specifically for the table's owner, making policies apply even to owner-run queries (superusers and BYPASSRLS roles still bypass regardless, since FORCE only affects the owner-bypass case)
BThis is a bug; RLS policies should always apply to every role including the owner, with no exceptions
CFORCE ROW LEVEL SECURITY makes RLS mandatory for every table in the database, not just the one it's applied to
DTable owners can never be affected by RLS under any configuration; this is a hard PostgreSQL limitation
What are the two core commands that set up PostgreSQL's built-in logical replication between two databases?
AOn the source (publisher) database: CREATE PUBLICATION my_pub FOR TABLE orders;, defining what changes to stream. On the target (subscriber) database: CREATE SUBSCRIPTION my_sub CONNECTION '...' PUBLICATION my_pub;, which connects to the publisher, performs an initial data copy of the published tables, and then continuously streams ongoing changes
BCREATE REPLICA on the source, CREATE STANDBY on the target
CALTER SYSTEM SET replication_mode = 'logical'; alone is sufficient; no per-table setup is needed
DLogical replication requires manually configuring recovery.conf, the same as physical streaming replication
pg_stat_statements has been accumulating query statistics for months, making it hard to tell which slow queries are from today's new deploy versus historical noise. What does SELECT pg_stat_statements_reset(); do?
AIt clears the currently accumulated statistics (call counts, total/mean execution time, and so on) for tracked queries, starting fresh from zero — a common practice right before or after a deploy specifically to isolate that deploy's query performance impact from everything measured before it
BIt permanently disables the pg_stat_statements extension until the server restarts
CIt deletes the actual query text history but keeps the numeric statistics intact
DIt only resets statistics for the currently connected session's own queries
Sign up free to play
Answer all 10 questions (7 more), see explanations for every answer, and track your score.