You signed in with another tab or window.Reload to refresh your session.You signed out in another tab or window.Reload to refresh your session.You switched accounts on another tab or window.Reload to refresh your session.Dismiss alert
Buildfarm member tick identified an issue where the policies in therelcache for a relation were were being replaced underneath a runningquery, leading to segfaults while processing the policies to be addedto a query. Similar to how TupleDesc RuleLocks are handled, add in aequalRSDesc() function to check if the policies have actually changedand, if not, swap back the rsdesc field (using the original instead ofthe temporairly built one; the whole structure is swapped and thenspecific fields swapped back). This now passes a CLOBBER_CACHE_ALWAYSfor me and should resolve the buildfarm error.In addition to addressing this, add a new chapter in Data Definitionunder Privileges which explains row security and provides examples ofits usage, change \d to always list policies (even if row security isdisabled- but note that it is disabled, or enabled with no policies),rework check_role_for_policy (it really didn't need the entire policy,but it did need to be using has_privs_of_role()), and change the fieldin pg_class to relrowsecurity from relhasrowsecurity, based onHeikki's suggestion. Also from Heikki, only issue SET ROW_SECURITY inpg_restore when talking to a 9.5+ server, list Bypass RLS in \du, anddocument --enable-row-security options for pg_dump and pg_restore.Lastly, fix a number of minor whitespace and typo issues from Heikki,Dimitri, add a missing #include, per Peter E, fix a few minorvariable-assigned-but-not-used and resource leak issues from Coverityand add tab completion for role attribute bypassrls as well.