--- title: All Your GUCs in a Row: row_security | daily.dev description: The PostgreSQL parameter row_security = off does not disable row-level security. It only decides whether a query that would be filtered by a policy returns an... canonical: https://daily.dev/posts/all-your-gucs-in-a-row-row-security-d1d1kw6me twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: All Your GUCs in a Row: row_security | daily.dev og:description: The PostgreSQL parameter row_security = off does not disable row-level security. It only decides whether a query that would be filtered by a policy returns an... og:url: https://daily.dev/posts/all-your-gucs-in-a-row-row-security-d1d1kw6me og:image: https://api.daily.dev/og/posts/d1d1kW6me.png og:image:alt: All Your GUCs in a Row: row_security og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # All Your GUCs in a Row: row_security **[Planet PostgreSQL](https://daily.dev/sources/planet-postgresql)** · 7 min read · 0 upvotes · 0 comments ## Summary The PostgreSQL parameter row_security = off does not disable row-level security. It only decides whether a query that would be filtered by a policy returns an error instead of filtered rows. The real bypass is the BYPASSRLS role attribute, which superusers have by their nature and other roles must be granted. Because of this, pg_dump sets row_security = off so a backup either gets every row or fails loudly, as seen with pg_cron's cron.job table, which has carried a row-level security policy since 2016. Using pg_dump's --enable-row-security flag silences the error but silently produces an incomplete backup instead, once causing an empty cron.job table with a zero exit status. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### Does setting row_security = off in PostgreSQL disable row-level security? No, it does not disable row-level security. It only changes what happens when a policy would apply: with row_security on, the query returns the filtered rows; with it off, the query raises error 42501 ('query would be affected by row-level security policy') and returns nothing. The actual bypass mechanism is the BYPASSRLS role attribute, held by superusers and roles granted it explicitly. _Working through RLS edge cases in Postgres? daily.dev surfaces practical database internals writeups like this._ ### Why does pg_dump fail with 'query would be affected by row-level security policy'? pg_dump sends SET row_security = off at the start of its connection so a backup either captures every row or fails outright, never silently omitting rows. If the role running pg_dump is subject to a row-level security policy (for example pg_cron's cron.job table, which has enforced a username-based policy since 2016), the dump errors instead of producing a partial table. Fixes: dump as a role with BYPASSRLS, or exclude the restricted table/schema entirely. _Hitting this during a Postgres backup? daily.dev tracks writeups on diagnosing RLS and pg_dump failures._ ### What does pg_dump's --enable-row-security flag actually do? It replaces pg_dump's default SET row_security = off with SET row_security = on, which stops the backup from erroring but makes it write only the rows the dumping role is allowed to see, silently omitting the rest. In one documented case with pg_cron's cron.job table, this produced a dump with an empty cron.job table and an exit status of zero, meaning the backup looked successful despite missing data. _Choosing pg_dump flags for a multi-tenant Postgres backup? daily.dev helps you spot options like this before they bite._ ## Similar posts on daily.dev - [All Your GUCs in a Row: lo\_compat\_privileges](https://daily.dev/posts/all-your-gucs-in-a-row-lo-compat-privileges-gezlrxrne) · Planet PostgreSQL · 0 upvotes · 0 comments - [All Your GUCs in a Row: quote\_all\_identifiers](https://daily.dev/posts/all-your-gucs-in-a-row-quote-all-identifiers-biskod2jv) · Planet PostgreSQL · 0 upvotes · 0 comments - [PostgreSQL row-level security for SaaS: what we measured](https://daily.dev/posts/postgresql-row-level-security-for-saas-what-we-measured-wxhmymmnr) · Planet PostgreSQL · 0 upvotes · 0 comments - [All Your GUCs in a Row: event\_triggers](https://daily.dev/posts/all-your-gucs-in-a-row-event-triggers-2eqdc3xmw) · Planet PostgreSQL · 1 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security), [#postgresql](https://daily.dev/tags/postgresql) [View this post on daily.dev](https://daily.dev/posts/all-your-gucs-in-a-row-row-security-d1d1kw6me) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"All Your GUCs in a Row: row_security","url":"https://daily.dev/posts/all-your-gucs-in-a-row-row-security-d1d1kw6me","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-row-security-d1d1kw6me"},"datePublished":"2026-11-01T14:02:19.004Z","dateModified":"2026-11-01T14:02:48.189Z","description":"The PostgreSQL parameter row_security = off does not disable row-level security. It only decides whether a query that would be filtered by a policy returns an...","image":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","thumbnailUrl":"https://media.daily.dev/image/upload/s--0_ODbtD2--/f_auto/v1722860399/public/Placeholder%2008","isAccessibleForFree":true,"articleSection":"Planet PostgreSQL","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Planet PostgreSQL","logo":"https://media.daily.dev/image/upload/logos/placeholder.jpg","url":"https://daily.dev/sources/planet-postgresql"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/all-your-gucs-in-a-row-row-security-d1d1kw6me","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security,postgresql","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Planet PostgreSQL","item":"https://daily.dev/sources/planet-postgresql"},{"@type":"ListItem","position":3,"name":"All Your GUCs in a Row: row_security"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/all-your-gucs-in-a-row-row-security-d1d1kw6me#faq","mainEntity":[{"@type":"Question","name":"Does setting row_security = off in PostgreSQL disable row-level security?","acceptedAnswer":{"@type":"Answer","text":"No, it does not disable row-level security. It only changes what happens when a policy would apply: with row_security on, the query returns the filtered rows; with it off, the query raises error 42501 ('query would be affected by row-level security policy') and returns nothing. The actual bypass mechanism is the BYPASSRLS role attribute, held by superusers and roles granted it explicitly. Working through RLS edge cases in Postgres? daily.dev surfaces practical database internals writeups like this."}},{"@type":"Question","name":"Why does pg_dump fail with 'query would be affected by row-level security policy'?","acceptedAnswer":{"@type":"Answer","text":"pg_dump sends SET row_security = off at the start of its connection so a backup either captures every row or fails outright, never silently omitting rows. If the role running pg_dump is subject to a row-level security policy (for example pg_cron's cron.job table, which has enforced a username-based policy since 2016), the dump errors instead of producing a partial table. Fixes: dump as a role with BYPASSRLS, or exclude the restricted table/schema entirely. Hitting this during a Postgres backup? daily.dev tracks writeups on diagnosing RLS and pg_dump failures."}},{"@type":"Question","name":"What does pg_dump's --enable-row-security flag actually do?","acceptedAnswer":{"@type":"Answer","text":"It replaces pg_dump's default SET row_security = off with SET row_security = on, which stops the backup from erroring but makes it write only the rows the dumping role is allowed to see, silently omitting the rest. In one documented case with pg_cron's cron.job table, this produced a dump with an empty cron.job table and an exit status of zero, meaning the backup looked successful despite missing data. Choosing pg_dump flags for a multi-tenant Postgres backup? daily.dev helps you spot options like this before they bite."}}]} ```