public inbox for [email protected]
help / color / mirror / Atom feed[PATCH 2/9] Move IS [NOT] NULL handling from BRIN support functions
9+ messages / 4 participants
[nested] [flat]
* [PATCH 2/9] Move IS [NOT] NULL handling from BRIN support functions
@ 2020-09-17 15:26 Tomas Vondra <[email protected]>
0 siblings, 0 replies; 9+ messages in thread
From: Tomas Vondra @ 2020-09-17 15:26 UTC (permalink / raw)
The handling of IS [NOT] NULL clauses is independent of an opclass, and
most of the code was exactly the same in both minmax and inclusion. So
instead move the code from support procedures to the AM methods etc.
This simplifies the code quite a bit - especially the support procedures
quite a bit, as they don't need to care about NULL values and flags at
all. It also means the IS [NOT] NULL clauses can be evaluated without
invoking the support procedure at all.
Author: Tomas Vondra <[email protected]>
Author: Nikita Glukhov <[email protected]>
Reviewed-by: Alvaro Herrera <[email protected]>
Reviewed-by: Mark Dilger <[email protected]>
Reviewed-by: Alexander Korotkov <[email protected]>
Reviewed-by: Masahiko Sawada <[email protected]>
Reviewed-by: John Naylor <[email protected]>
Discussion: https://postgr.es/m/[email protected]
---
src/backend/access/brin/brin.c | 293 +++++++++++++++++------
src/backend/access/brin/brin_inclusion.c | 106 +-------
src/backend/access/brin/brin_minmax.c | 103 +-------
src/include/access/brin_internal.h | 3 +
4 files changed, 239 insertions(+), 266 deletions(-)
diff --git a/src/backend/access/brin/brin.c b/src/backend/access/brin/brin.c
index dc187153aa..14da9ed17f 100644
--- a/src/backend/access/brin/brin.c
+++ b/src/backend/access/brin/brin.c
@@ -35,6 +35,7 @@
#include "storage/freespace.h"
#include "utils/acl.h"
#include "utils/builtins.h"
+#include "utils/datum.h"
#include "utils/index_selfuncs.h"
#include "utils/memutils.h"
#include "utils/rel.h"
@@ -77,7 +78,9 @@ static void form_and_insert_tuple(BrinBuildState *state);
static void union_tuples(BrinDesc *bdesc, BrinMemTuple *a,
BrinTuple *b);
static void brin_vacuum_scan(Relation idxrel, BufferAccessStrategy strategy);
-
+static bool add_values_to_range(Relation idxRel, BrinDesc *bdesc,
+ BrinMemTuple *dtup, Datum *values, bool *nulls);
+static bool check_null_keys(BrinValues *bval, ScanKey *nullkeys, int nnullkeys);
/*
* BRIN handler function: return IndexAmRoutine with access method parameters
@@ -179,7 +182,6 @@ brininsert(Relation idxRel, Datum *values, bool *nulls,
OffsetNumber off;
BrinTuple *brtup;
BrinMemTuple *dtup;
- int keyno;
CHECK_FOR_INTERRUPTS();
@@ -243,31 +245,7 @@ brininsert(Relation idxRel, Datum *values, bool *nulls,
dtup = brin_deform_tuple(bdesc, brtup, NULL);
- /*
- * Compare the key values of the new tuple to the stored index values;
- * our deformed tuple will get updated if the new tuple doesn't fit
- * the original range (note this means we can't break out of the loop
- * early). Make a note of whether this happens, so that we know to
- * insert the modified tuple later.
- */
- for (keyno = 0; keyno < bdesc->bd_tupdesc->natts; keyno++)
- {
- Datum result;
- BrinValues *bval;
- FmgrInfo *addValue;
-
- bval = &dtup->bt_columns[keyno];
- addValue = index_getprocinfo(idxRel, keyno + 1,
- BRIN_PROCNUM_ADDVALUE);
- result = FunctionCall4Coll(addValue,
- idxRel->rd_indcollation[keyno],
- PointerGetDatum(bdesc),
- PointerGetDatum(bval),
- values[keyno],
- nulls[keyno]);
- /* if that returned true, we need to insert the updated tuple */
- need_insert |= DatumGetBool(result);
- }
+ need_insert = add_values_to_range(idxRel, bdesc, dtup, values, nulls);
if (!need_insert)
{
@@ -390,8 +368,10 @@ bringetbitmap(IndexScanDesc scan, TIDBitmap *tbm)
BrinMemTuple *dtup;
BrinTuple *btup = NULL;
Size btupsz = 0;
- ScanKey **keys;
- int *nkeys;
+ ScanKey **keys,
+ **nullkeys;
+ int *nkeys,
+ *nnullkeys;
int keyno;
opaque = (BrinOpaque *) scan->opaque;
@@ -416,10 +396,13 @@ bringetbitmap(IndexScanDesc scan, TIDBitmap *tbm)
/*
* Make room for per-attribute lists of scan keys that we'll pass to the
- * consistent support procedure.
+ * consistent support procedure. We keep null and regular keys separate,
+ * so that we can easily pass regular keys to the consistent function.
*/
keys = palloc0(sizeof(ScanKey *) * bdesc->bd_tupdesc->natts);
+ nullkeys = palloc0(sizeof(ScanKey *) * bdesc->bd_tupdesc->natts);
nkeys = palloc0(sizeof(int) * bdesc->bd_tupdesc->natts);
+ nnullkeys = palloc0(sizeof(int) * bdesc->bd_tupdesc->natts);
/*
* Preprocess the scan keys - split them into per-attribute arrays.
@@ -440,23 +423,24 @@ bringetbitmap(IndexScanDesc scan, TIDBitmap *tbm)
TupleDescAttr(bdesc->bd_tupdesc,
keyattno - 1)->attcollation));
- /* First time we see this index attribute, so init as needed. */
- if (!keys[keyattno-1])
+ /*
+ * First time we see this index attribute, so init as needed.
+ *
+ * This is a bit of an overkill - we don't know how many scan
+ * keys are there for a given attribute, so we simply allocate
+ * the largest number possible (as if all scan keys belonged to
+ * the same attribute). This may waste a bit of memory, but we
+ * only expect small number of scan keys in general, so this
+ * should be negligible, and it's probably cheaper than having
+ * to repalloc repeatedly.
+ */
+ if (consistentFn[keyattno - 1].fn_oid == InvalidOid)
{
FmgrInfo *tmp;
- /*
- * This is a bit of an overkill - we don't know how many
- * scan keys are there for this attribute, so we simply
- * allocate the largest number possible. This may waste
- * a bit of memory, but we only expect small number of
- * scan keys in general, so this should be negligible,
- * and it's cheaper than having to repalloc repeatedly.
- */
- keys[keyattno - 1] = palloc0(sizeof(ScanKey) * scan->numberOfKeys);
-
- /* First time this column, so look up consistent function */
- Assert(consistentFn[keyattno - 1].fn_oid == InvalidOid);
+ /* No key/null arrays for this attribute. */
+ Assert((keys[keyattno - 1] == NULL) && (nkeys[keyattno - 1] == 0));
+ Assert((nullkeys[keyattno - 1] == NULL) && (nnullkeys[keyattno - 1] == 0));
tmp = index_getprocinfo(idxRel, keyattno,
BRIN_PROCNUM_CONSISTENT);
@@ -464,9 +448,23 @@ bringetbitmap(IndexScanDesc scan, TIDBitmap *tbm)
CurrentMemoryContext);
}
- /* Add key to the per-attribute array. */
- keys[keyattno - 1][nkeys[keyattno - 1]] = key;
- nkeys[keyattno - 1]++;
+ /* Add key to the proper per-attribute array. */
+ if (key->sk_flags & SK_ISNULL)
+ {
+ if (!nullkeys[keyattno - 1])
+ nullkeys[keyattno - 1] = palloc0(sizeof(ScanKey) * scan->numberOfKeys);
+
+ nullkeys[keyattno - 1][nnullkeys[keyattno - 1]] = key;
+ nnullkeys[keyattno - 1]++;
+ }
+ else
+ {
+ if (!keys[keyattno - 1])
+ keys[keyattno - 1] = palloc0(sizeof(ScanKey) * scan->numberOfKeys);
+
+ keys[keyattno - 1][nkeys[keyattno - 1]] = key;
+ nkeys[keyattno - 1]++;
+ }
}
/* allocate an initial in-memory tuple, out of the per-range memcxt */
@@ -544,15 +542,57 @@ bringetbitmap(IndexScanDesc scan, TIDBitmap *tbm)
BrinValues *bval;
Datum add;
- /* skip attributes without any san keys */
- if (nkeys[attno - 1] == 0)
+ /*
+ * skip attributes without any scan keys (both regular
+ * and IS [NOT] NULL)
+ */
+ if (nkeys[attno - 1] == 0 && nnullkeys[attno - 1] == 0)
continue;
bval = &dtup->bt_columns[attno - 1];
+ /*
+ * First check if there are any IS [NOT] NULL scan keys,
+ * and if we're violating them. In that case we can
+ * terminate early, without invoking the support function.
+ *
+ * As there may be more keys, we can only detemine mismatch
+ * within this loop.
+ */
+ if (bdesc->bd_info[attno - 1]->oi_regular_nulls &&
+ !check_null_keys(bval, nullkeys[attno - 1],
+ nnullkeys[attno - 1]))
+ {
+ /*
+ * If any of the IS [NOT] NULL keys failed, the page
+ * range as a whole can't pass. So terminate the loop.
+ */
+ addrange = false;
+ break;
+ }
+
+ /*
+ * So either there are no IS [NOT] NULL keys, or all passed.
+ * If there are no regular scan keys, we're done - the page
+ * range matches. If there are regular keys, but the page
+ * range is marked as 'all nulls' it can't possibly pass
+ * (we're assuming the operators are strict).
+ */
+
+ /* No regular scan keys - page range as a whole passes. */
+ if (!nkeys[attno - 1])
+ continue;
+
Assert((nkeys[attno - 1] > 0) &&
(nkeys[attno - 1] <= scan->numberOfKeys));
+ /* If it is all nulls, it cannot possibly be consistent. */
+ if (bval->bv_allnulls)
+ {
+ addrange = false;
+ break;
+ }
+
/*
* Check whether the scan key is consistent with the page
* range values; if so, have the pages in the range added
@@ -695,7 +735,6 @@ brinbuildCallback(Relation index,
{
BrinBuildState *state = (BrinBuildState *) brstate;
BlockNumber thisblock;
- int i;
thisblock = ItemPointerGetBlockNumber(tid);
@@ -724,25 +763,8 @@ brinbuildCallback(Relation index,
}
/* Accumulate the current tuple into the running state */
- for (i = 0; i < state->bs_bdesc->bd_tupdesc->natts; i++)
- {
- FmgrInfo *addValue;
- BrinValues *col;
- Form_pg_attribute attr = TupleDescAttr(state->bs_bdesc->bd_tupdesc, i);
-
- col = &state->bs_dtuple->bt_columns[i];
- addValue = index_getprocinfo(index, i + 1,
- BRIN_PROCNUM_ADDVALUE);
-
- /*
- * Update dtuple state, if and as necessary.
- */
- FunctionCall4Coll(addValue,
- attr->attcollation,
- PointerGetDatum(state->bs_bdesc),
- PointerGetDatum(col),
- values[i], isnull[i]);
- }
+ (void) add_values_to_range(index, state->bs_bdesc, state->bs_dtuple,
+ values, isnull);
}
/*
@@ -1521,6 +1543,39 @@ union_tuples(BrinDesc *bdesc, BrinMemTuple *a, BrinTuple *b)
FmgrInfo *unionFn;
BrinValues *col_a = &a->bt_columns[keyno];
BrinValues *col_b = &db->bt_columns[keyno];
+ BrinOpcInfo *opcinfo = bdesc->bd_info[keyno];
+
+ if (opcinfo->oi_regular_nulls)
+ {
+ /* Adjust "hasnulls". */
+ if (!col_a->bv_hasnulls && col_b->bv_hasnulls)
+ col_a->bv_hasnulls = true;
+
+ /* If there are no values in B, there's nothing left to do. */
+ if (col_b->bv_allnulls)
+ continue;
+
+ /*
+ * Adjust "allnulls". If A doesn't have values, just copy the
+ * values from B into A, and we're done. We cannot run the
+ * operators in this case, because values in A might contain
+ * garbage. Note we already established that B contains values.
+ */
+ if (col_a->bv_allnulls)
+ {
+ int i;
+
+ col_a->bv_allnulls = false;
+
+ for (i = 0; i < opcinfo->oi_nstored; i++)
+ col_a->bv_values[i] =
+ datumCopy(col_b->bv_values[i],
+ opcinfo->oi_typcache[i]->typbyval,
+ opcinfo->oi_typcache[i]->typlen);
+
+ continue;
+ }
+ }
unionFn = index_getprocinfo(bdesc->bd_index, keyno + 1,
BRIN_PROCNUM_UNION);
@@ -1574,3 +1629,103 @@ brin_vacuum_scan(Relation idxrel, BufferAccessStrategy strategy)
*/
FreeSpaceMapVacuum(idxrel);
}
+
+static bool
+add_values_to_range(Relation idxRel, BrinDesc *bdesc, BrinMemTuple *dtup,
+ Datum *values, bool *nulls)
+{
+ int keyno;
+ bool modified = false;
+
+ /*
+ * Compare the key values of the new tuple to the stored index values;
+ * our deformed tuple will get updated if the new tuple doesn't fit
+ * the original range (note this means we can't break out of the loop
+ * early). Make a note of whether this happens, so that we know to
+ * insert the modified tuple later.
+ */
+ for (keyno = 0; keyno < bdesc->bd_tupdesc->natts; keyno++)
+ {
+ Datum result;
+ BrinValues *bval;
+ FmgrInfo *addValue;
+
+ bval = &dtup->bt_columns[keyno];
+
+ if (bdesc->bd_info[keyno]->oi_regular_nulls && nulls[keyno])
+ {
+ /*
+ * If the new value is null, we record that we saw it if it's
+ * the first one; otherwise, there's nothing to do.
+ */
+ if (!bval->bv_hasnulls)
+ {
+ bval->bv_hasnulls = true;
+ modified = true;
+ }
+
+ continue;
+ }
+
+ addValue = index_getprocinfo(idxRel, keyno + 1,
+ BRIN_PROCNUM_ADDVALUE);
+ result = FunctionCall4Coll(addValue,
+ idxRel->rd_indcollation[keyno],
+ PointerGetDatum(bdesc),
+ PointerGetDatum(bval),
+ values[keyno],
+ nulls[keyno]);
+ /* if that returned true, we need to insert the updated tuple */
+ modified |= DatumGetBool(result);
+ }
+
+ return modified;
+}
+
+static bool
+check_null_keys(BrinValues *bval, ScanKey *nullkeys, int nnullkeys)
+{
+ int keyno;
+
+ /*
+ * First check if there are any IS [NOT] NULL scan keys, and if we're
+ * violating them.
+ */
+ for (keyno = 0; keyno < nnullkeys; keyno++)
+ {
+ ScanKey key = nullkeys[keyno];
+
+ Assert(key->sk_attno == bval->bv_attno);
+
+ /* Handle only IS NULL/IS NOT NULL tests */
+ if (!(key->sk_flags & SK_ISNULL))
+ continue;
+
+ if (key->sk_flags & SK_SEARCHNULL)
+ {
+ /* IS NULL scan key, but range has no NULLs */
+ if (!bval->bv_allnulls && !bval->bv_hasnulls)
+ return false;
+ }
+ else if (key->sk_flags & SK_SEARCHNOTNULL)
+ {
+ /*
+ * For IS NOT NULL, we can only skip ranges that are known to
+ * have only nulls.
+ */
+ if (bval->bv_allnulls)
+ return false;
+ }
+ else
+ {
+ /*
+ * Neither IS NULL nor IS NOT NULL was used; assume all indexable
+ * operators are strict and thus return false with NULL value in
+ * the scan key.
+ */
+ return false;
+ }
+ }
+
+ return true;
+}
diff --git a/src/backend/access/brin/brin_inclusion.c b/src/backend/access/brin/brin_inclusion.c
index 215bc794d3..f4730be3b9 100644
--- a/src/backend/access/brin/brin_inclusion.c
+++ b/src/backend/access/brin/brin_inclusion.c
@@ -110,6 +110,7 @@ brin_inclusion_opcinfo(PG_FUNCTION_ARGS)
*/
result = palloc0(MAXALIGN(SizeofBrinOpcInfo(3)) + sizeof(InclusionOpaque));
result->oi_nstored = 3;
+ result->oi_regular_nulls = true;
result->oi_opaque = (InclusionOpaque *)
MAXALIGN((char *) result + SizeofBrinOpcInfo(3));
@@ -141,7 +142,7 @@ brin_inclusion_add_value(PG_FUNCTION_ARGS)
BrinDesc *bdesc = (BrinDesc *) PG_GETARG_POINTER(0);
BrinValues *column = (BrinValues *) PG_GETARG_POINTER(1);
Datum newval = PG_GETARG_DATUM(2);
- bool isnull = PG_GETARG_BOOL(3);
+ bool isnull PG_USED_FOR_ASSERTS_ONLY = PG_GETARG_BOOL(3);
Oid colloid = PG_GET_COLLATION();
FmgrInfo *finfo;
Datum result;
@@ -149,18 +150,7 @@ brin_inclusion_add_value(PG_FUNCTION_ARGS)
AttrNumber attno;
Form_pg_attribute attr;
- /*
- * If the new value is null, we record that we saw it if it's the first
- * one; otherwise, there's nothing to do.
- */
- if (isnull)
- {
- if (column->bv_hasnulls)
- PG_RETURN_BOOL(false);
-
- column->bv_hasnulls = true;
- PG_RETURN_BOOL(true);
- }
+ Assert(!isnull);
attno = column->bv_attno;
attr = TupleDescAttr(bdesc->bd_tupdesc, attno - 1);
@@ -264,63 +254,6 @@ brin_inclusion_consistent(PG_FUNCTION_ARGS)
int nkeys = PG_GETARG_INT32(3);
Oid colloid = PG_GET_COLLATION();
int keyno;
- bool regular_keys = false;
-
- /*
- * First check if there are any IS NULL scan keys, and if we're
- * violating them. In that case we can terminate early, without
- * inspecting the ranges.
- */
- for (keyno = 0; keyno < nkeys; keyno++)
- {
- ScanKey key = keys[keyno];
-
- Assert(key->sk_attno == column->bv_attno);
-
- /* handle IS NULL/IS NOT NULL tests */
- if (key->sk_flags & SK_ISNULL)
- {
- if (key->sk_flags & SK_SEARCHNULL)
- {
- if (column->bv_allnulls || column->bv_hasnulls)
- continue; /* this key is fine, continue */
-
- PG_RETURN_BOOL(false);
- }
-
- /*
- * For IS NOT NULL, we can only skip ranges that are known to have
- * only nulls.
- */
- if (key->sk_flags & SK_SEARCHNOTNULL)
- {
- if (column->bv_allnulls)
- PG_RETURN_BOOL(false);
-
- continue;
- }
-
- /*
- * Neither IS NULL nor IS NOT NULL was used; assume all indexable
- * operators are strict and return false.
- */
- PG_RETURN_BOOL(false);
- }
- else
- /* note we have regular (non-NULL) scan keys */
- regular_keys = true;
- }
-
- /*
- * If the page range is all nulls, it cannot possibly be consistent if
- * there are some regular scan keys.
- */
- if (column->bv_allnulls && regular_keys)
- PG_RETURN_BOOL(false);
-
- /* If there are no regular keys, the page range is considered consistent. */
- if (!regular_keys)
- PG_RETURN_BOOL(true);
/* It has to be checked, if it contains elements that are not mergeable. */
if (DatumGetBool(column->bv_values[INCLUSION_UNMERGEABLE]))
@@ -331,9 +264,8 @@ brin_inclusion_consistent(PG_FUNCTION_ARGS)
{
ScanKey key = keys[keyno];
- /* ignore IS NULL/IS NOT NULL tests handled above */
- if (key->sk_flags & SK_ISNULL)
- continue;
+ /* NULL keys are handled and filtered-out in bringetbitmap */
+ Assert(!(key->sk_flags & SK_ISNULL));
/*
* When there are multiple scan keys, failure to meet the
@@ -572,37 +504,11 @@ brin_inclusion_union(PG_FUNCTION_ARGS)
Datum result;
Assert(col_a->bv_attno == col_b->bv_attno);
-
- /* Adjust "hasnulls". */
- if (!col_a->bv_hasnulls && col_b->bv_hasnulls)
- col_a->bv_hasnulls = true;
-
- /* If there are no values in B, there's nothing left to do. */
- if (col_b->bv_allnulls)
- PG_RETURN_VOID();
+ Assert(!col_a->bv_allnulls && !col_b->bv_allnulls);
attno = col_a->bv_attno;
attr = TupleDescAttr(bdesc->bd_tupdesc, attno - 1);
- /*
- * Adjust "allnulls". If A doesn't have values, just copy the values from
- * B into A, and we're done. We cannot run the operators in this case,
- * because values in A might contain garbage. Note we already established
- * that B contains values.
- */
- if (col_a->bv_allnulls)
- {
- col_a->bv_allnulls = false;
- col_a->bv_values[INCLUSION_UNION] =
- datumCopy(col_b->bv_values[INCLUSION_UNION],
- attr->attbyval, attr->attlen);
- col_a->bv_values[INCLUSION_UNMERGEABLE] =
- col_b->bv_values[INCLUSION_UNMERGEABLE];
- col_a->bv_values[INCLUSION_CONTAINS_EMPTY] =
- col_b->bv_values[INCLUSION_CONTAINS_EMPTY];
- PG_RETURN_VOID();
- }
-
/* If B includes empty elements, mark A similarly, if needed. */
if (!DatumGetBool(col_a->bv_values[INCLUSION_CONTAINS_EMPTY]) &&
DatumGetBool(col_b->bv_values[INCLUSION_CONTAINS_EMPTY]))
diff --git a/src/backend/access/brin/brin_minmax.c b/src/backend/access/brin/brin_minmax.c
index 12878ff3a0..6c8852d404 100644
--- a/src/backend/access/brin/brin_minmax.c
+++ b/src/backend/access/brin/brin_minmax.c
@@ -48,6 +48,7 @@ brin_minmax_opcinfo(PG_FUNCTION_ARGS)
result = palloc0(MAXALIGN(SizeofBrinOpcInfo(2)) +
sizeof(MinmaxOpaque));
result->oi_nstored = 2;
+ result->oi_regular_nulls = true;
result->oi_opaque = (MinmaxOpaque *)
MAXALIGN((char *) result + SizeofBrinOpcInfo(2));
result->oi_typcache[0] = result->oi_typcache[1] =
@@ -69,7 +70,7 @@ brin_minmax_add_value(PG_FUNCTION_ARGS)
BrinDesc *bdesc = (BrinDesc *) PG_GETARG_POINTER(0);
BrinValues *column = (BrinValues *) PG_GETARG_POINTER(1);
Datum newval = PG_GETARG_DATUM(2);
- bool isnull = PG_GETARG_DATUM(3);
+ bool isnull PG_USED_FOR_ASSERTS_ONLY = PG_GETARG_DATUM(3);
Oid colloid = PG_GET_COLLATION();
FmgrInfo *cmpFn;
Datum compar;
@@ -77,18 +78,7 @@ brin_minmax_add_value(PG_FUNCTION_ARGS)
Form_pg_attribute attr;
AttrNumber attno;
- /*
- * If the new value is null, we record that we saw it if it's the first
- * one; otherwise, there's nothing to do.
- */
- if (isnull)
- {
- if (column->bv_hasnulls)
- PG_RETURN_BOOL(false);
-
- column->bv_hasnulls = true;
- PG_RETURN_BOOL(true);
- }
+ Assert(!isnull);
attno = column->bv_attno;
attr = TupleDescAttr(bdesc->bd_tupdesc, attno - 1);
@@ -152,72 +142,14 @@ brin_minmax_consistent(PG_FUNCTION_ARGS)
int nkeys = PG_GETARG_INT32(3);
Oid colloid = PG_GET_COLLATION();
int keyno;
- bool regular_keys = false;
-
- /*
- * First check if there are any IS NULL scan keys, and if we're
- * violating them. In that case we can terminate early, without
- * inspecting the ranges.
- */
- for (keyno = 0; keyno < nkeys; keyno++)
- {
- ScanKey key = keys[keyno];
-
- Assert(key->sk_attno == column->bv_attno);
-
- /* handle IS NULL/IS NOT NULL tests */
- if (key->sk_flags & SK_ISNULL)
- {
- if (key->sk_flags & SK_SEARCHNULL)
- {
- if (column->bv_allnulls || column->bv_hasnulls)
- continue; /* this key is fine, continue */
-
- PG_RETURN_BOOL(false);
- }
-
- /*
- * For IS NOT NULL, we can only skip ranges that are known to have
- * only nulls.
- */
- if (key->sk_flags & SK_SEARCHNOTNULL)
- {
- if (column->bv_allnulls)
- PG_RETURN_BOOL(false);
-
- continue;
- }
-
- /*
- * Neither IS NULL nor IS NOT NULL was used; assume all indexable
- * operators are strict and return false.
- */
- PG_RETURN_BOOL(false);
- }
- else
- /* note we have regular (non-NULL) scan keys */
- regular_keys = true;
- }
-
- /*
- * If the page range is all nulls, it cannot possibly be consistent if
- * there are some regular scan keys.
- */
- if (column->bv_allnulls && regular_keys)
- PG_RETURN_BOOL(false);
-
- /* If there are no regular keys, the page range is considered consistent. */
- if (!regular_keys)
- PG_RETURN_BOOL(true);
/* Check that the range is consistent with all scan keys. */
for (keyno = 0; keyno < nkeys; keyno++)
{
ScanKey key = keys[keyno];
- /* ignore IS NULL/IS NOT NULL tests handled above */
- if (key->sk_flags & SK_ISNULL)
- continue;
+ /* NULL keys are handled and filtered-out in bringetbitmap */
+ Assert(!(key->sk_flags & SK_ISNULL));
/*
* When there are multiple scan keys, failure to meet the
@@ -308,34 +240,11 @@ brin_minmax_union(PG_FUNCTION_ARGS)
bool needsadj;
Assert(col_a->bv_attno == col_b->bv_attno);
-
- /* Adjust "hasnulls" */
- if (!col_a->bv_hasnulls && col_b->bv_hasnulls)
- col_a->bv_hasnulls = true;
-
- /* If there are no values in B, there's nothing left to do */
- if (col_b->bv_allnulls)
- PG_RETURN_VOID();
+ Assert(!col_a->bv_allnulls && !col_b->bv_allnulls);
attno = col_a->bv_attno;
attr = TupleDescAttr(bdesc->bd_tupdesc, attno - 1);
- /*
- * Adjust "allnulls". If A doesn't have values, just copy the values from
- * B into A, and we're done. We cannot run the operators in this case,
- * because values in A might contain garbage. Note we already established
- * that B contains values.
- */
- if (col_a->bv_allnulls)
- {
- col_a->bv_allnulls = false;
- col_a->bv_values[0] = datumCopy(col_b->bv_values[0],
- attr->attbyval, attr->attlen);
- col_a->bv_values[1] = datumCopy(col_b->bv_values[1],
- attr->attbyval, attr->attlen);
- PG_RETURN_VOID();
- }
-
/* Adjust minimum, if B's min is less than A's min */
finfo = minmax_get_strategy_procinfo(bdesc, attno, attr->atttypid,
BTLessStrategyNumber);
diff --git a/src/include/access/brin_internal.h b/src/include/access/brin_internal.h
index 78c89a6961..79440ebe7b 100644
--- a/src/include/access/brin_internal.h
+++ b/src/include/access/brin_internal.h
@@ -27,6 +27,9 @@ typedef struct BrinOpcInfo
/* Number of columns stored in an index column of this opclass */
uint16 oi_nstored;
+ /* Regular processing of NULLs in BrinValues? */
+ bool oi_regular_nulls;
+
/* Opaque pointer for the opclass' private use */
void *oi_opaque;
--
2.26.2
--------------22A4B241170149838D4D1F8F
Content-Type: text/x-patch; charset=UTF-8;
name="0003-Optimize-allocations-in-bringetbitmap-20210215.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename*0="0003-Optimize-allocations-in-bringetbitmap-20210215.patch"
^ permalink raw reply [nested|flat] 9+ messages in thread
* improve predefined roles documentation
@ 2024-06-13 19:48 Nathan Bossart <[email protected]>
2024-06-13 20:05 ` Re: improve predefined roles documentation David G. Johnston <[email protected]>
2024-06-17 18:10 ` Re: improve predefined roles documentation Robert Haas <[email protected]>
0 siblings, 2 replies; 9+ messages in thread
From: Nathan Bossart @ 2024-06-13 19:48 UTC (permalink / raw)
To: pgsql-hackers
IMHO there are a couple of opportunities for improving the predefined roles
documentation [0]:
* Several of the roles in the table do not have corresponding descriptions
in the paragraphs below the table (e.g., pg_read_all_data,
pg_write_all_data, pg_checkpoint, pg_maintain,
pg_use_reserved_connections, and pg_create_subscription). Furthermore,
IMHO it is weird to have some of the information in the table and some
more in a paragraph down the page.
* The table has grown quite a bit over the years, but the entries are
basically unordered, requiring readers to perform a linear search (O(n))
to find information about a specific role.
* Documentation that refers to these roles cannot link to a specific one.
Currently, we just link to the page or the table.
I think we could improve matters by abandoning the table and instead
documenting these roles more like we document GUCs, i.e., each one has a
section below it where we can document it in as much detail as we want.
Some of these roles should probably be documented together (e.g.,
pg_read_all_data and pg_write_all_data), so the ordering is unlikely to be
perfect, but I'm hoping it would still be a net improvement.
Thoughts?
[0] https://www.postgresql.org/docs/devel/predefined-roles.html
--
nathan
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: improve predefined roles documentation
2024-06-13 19:48 improve predefined roles documentation Nathan Bossart <[email protected]>
@ 2024-06-13 20:05 ` David G. Johnston <[email protected]>
2024-06-13 20:11 ` Re: improve predefined roles documentation Nathan Bossart <[email protected]>
1 sibling, 1 reply; 9+ messages in thread
From: David G. Johnston @ 2024-06-13 20:05 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: pgsql-hackers
On Thu, Jun 13, 2024 at 12:48 PM Nathan Bossart <[email protected]>
wrote:
> I think we could improve matters by abandoning the table and instead
> documenting these roles more like we document GUCs, i.e., each one has a
> section below it where we can document it in as much detail as we want.
>
>
One of the main attributes for the GUCs is their category. If we want to
improve organization we'd need to assign categories first. We already
implicitly do so in the description section where we do group them together
and explain why - but it is all informal. But getting rid of those
groupings and descriptions and isolating each role so it can be linked to
more easily seems like a net loss in usability.
I'm against getting rid of the table. If we do add authoritative
subsection anchors we should just do like we do in System Catalogs and make
the existing table name values hyperlinks to those newly added anchors.
Breaking the one table up into multiple tables along category lines is
something to consider.
David J.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: improve predefined roles documentation
2024-06-13 19:48 improve predefined roles documentation Nathan Bossart <[email protected]>
2024-06-13 20:05 ` Re: improve predefined roles documentation David G. Johnston <[email protected]>
@ 2024-06-13 20:11 ` Nathan Bossart <[email protected]>
0 siblings, 0 replies; 9+ messages in thread
From: Nathan Bossart @ 2024-06-13 20:11 UTC (permalink / raw)
To: David G. Johnston <[email protected]>; +Cc: pgsql-hackers
On Thu, Jun 13, 2024 at 01:05:33PM -0700, David G. Johnston wrote:
> One of the main attributes for the GUCs is their category. If we want to
> improve organization we'd need to assign categories first. We already
> implicitly do so in the description section where we do group them together
> and explain why - but it is all informal. But getting rid of those
> groupings and descriptions and isolating each role so it can be linked to
> more easily seems like a net loss in usability.
What I had in mind is that we would retain these groupings. I agree that
isolating roles like pg_read_all_data and pg_write_all_data would be no
good.
--
nathan
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: improve predefined roles documentation
2024-06-13 19:48 improve predefined roles documentation Nathan Bossart <[email protected]>
@ 2024-06-17 18:10 ` Robert Haas <[email protected]>
2024-06-18 16:52 ` Re: improve predefined roles documentation Nathan Bossart <[email protected]>
1 sibling, 1 reply; 9+ messages in thread
From: Robert Haas @ 2024-06-17 18:10 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: pgsql-hackers
On Thu, Jun 13, 2024 at 3:48 PM Nathan Bossart <[email protected]> wrote:
> I think we could improve matters by abandoning the table and instead
> documenting these roles more like we document GUCs, i.e., each one has a
> section below it where we can document it in as much detail as we want.
> Some of these roles should probably be documented together (e.g.,
> pg_read_all_data and pg_write_all_data), so the ordering is unlikely to be
> perfect, but I'm hoping it would still be a net improvement.
+1. I'm not sure about all of the details, but I like the general idea.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: improve predefined roles documentation
2024-06-13 19:48 improve predefined roles documentation Nathan Bossart <[email protected]>
2024-06-17 18:10 ` Re: improve predefined roles documentation Robert Haas <[email protected]>
@ 2024-06-18 16:52 ` Nathan Bossart <[email protected]>
2024-06-21 02:57 ` Re: improve predefined roles documentation David G. Johnston <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Nathan Bossart @ 2024-06-18 16:52 UTC (permalink / raw)
To: Robert Haas <[email protected]>; +Cc: pgsql-hackers
On Mon, Jun 17, 2024 at 02:10:22PM -0400, Robert Haas wrote:
> On Thu, Jun 13, 2024 at 3:48 PM Nathan Bossart <[email protected]> wrote:
>> I think we could improve matters by abandoning the table and instead
>> documenting these roles more like we document GUCs, i.e., each one has a
>> section below it where we can document it in as much detail as we want.
>> Some of these roles should probably be documented together (e.g.,
>> pg_read_all_data and pg_write_all_data), so the ordering is unlikely to be
>> perfect, but I'm hoping it would still be a net improvement.
>
> +1. I'm not sure about all of the details, but I like the general idea.
Here is a first try. I did pretty much exactly what I proposed in the
quoted text, so I don't have much else to say about it. I didn't see an
easy way to specify multiple ids and xreflabels for a given entry, so the
entries that describe multiple roles just use the name of the first role
listed. In practice, I think this just means you need to do a little extra
work when linking to one of the other roles from elsewhere in the docs,
which doesn't seem too terrible.
--
nathan
From 89db4a562ddb07aa1215608fb116b511143b0e66 Mon Sep 17 00:00:00 2001
From: Nathan Bossart <[email protected]>
Date: Tue, 18 Jun 2024 11:38:40 -0500
Subject: [PATCH v1 1/1] revamp predefined roles documentation
---
doc/src/sgml/config.sgml | 2 +-
doc/src/sgml/monitoring.sgml | 4 +-
doc/src/sgml/ref/checkpoint.sgml | 2 +-
doc/src/sgml/ref/reindex.sgml | 2 +-
doc/src/sgml/user-manag.sgml | 339 ++++++++++++++++---------------
5 files changed, 185 insertions(+), 164 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 698169afdb..b9fd3f3bd6 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -731,7 +731,7 @@ include_dir 'conf.d'
<para>
Determines the number of connection <quote>slots</quote> that are
reserved for connections by roles with privileges of the
- <link linkend="predefined-roles-table"><literal>pg_use_reserved_connections</literal></link>
+ <xref linkend="predefined-role-pg-use-reserved-connections"/>
role. Whenever the number of free connection slots is greater than
<xref linkend="guc-superuser-reserved-connections"/> but less than or
equal to the sum of <varname>superuser_reserved_connections</varname>
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index b2ad9b446f..133ad462cb 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -286,8 +286,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
other sessions, many columns will be null. Note, however, that the
existence of a session and its general properties such as its sessions user
and database are visible to all users. Superusers and roles with privileges of
- built-in role <literal>pg_read_all_stats</literal> (see also <xref
- linkend="predefined-roles"/>) can see all the information about all sessions.
+ built-in role <link linkend="predefined-role-pg-read-all-settings"><literal>pg_read_all_stats</literal></link>
+ can see all the information about all sessions.
</para>
<table id="monitoring-stats-dynamic-views-table">
diff --git a/doc/src/sgml/ref/checkpoint.sgml b/doc/src/sgml/ref/checkpoint.sgml
index 28a1d717b8..db011a47d0 100644
--- a/doc/src/sgml/ref/checkpoint.sgml
+++ b/doc/src/sgml/ref/checkpoint.sgml
@@ -53,7 +53,7 @@ CHECKPOINT
<para>
Only superusers or users with the privileges of
- the <link linkend="predefined-roles-table"><literal>pg_checkpoint</literal></link>
+ the <xref linkend="predefined-role-pg-checkpoint"/>
role can call <command>CHECKPOINT</command>.
</para>
</refsect1>
diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml
index 2942dccf1e..dcf70d14bc 100644
--- a/doc/src/sgml/ref/reindex.sgml
+++ b/doc/src/sgml/ref/reindex.sgml
@@ -305,7 +305,7 @@ REINDEX [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] { DA
partitioned table, such commands skip the privilege checks when processing
the individual partitions. Reindexing a schema or database requires being the
owner of that schema or database or having privileges of the
- <link linkend="predefined-roles-table"><literal>pg_maintain</literal></link>
+ <xref linkend="predefined-role-pg-maintain"/>
role. Note specifically that it's thus
possible for non-superusers to rebuild indexes of tables owned by
other users. However, as a special exception,
diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml
index 07a16247d7..1d3805d303 100644
--- a/doc/src/sgml/user-manag.sgml
+++ b/doc/src/sgml/user-manag.sgml
@@ -590,101 +590,71 @@ DROP ROLE doomed_role;
and information. Administrators (including roles that have the
<literal>CREATEROLE</literal> privilege) can <command>GRANT</command> these
roles to users and/or other roles in their environment, providing those
- users with access to the specified capabilities and information.
+ users with access to the specified capabilities and information. For
+ example:
+
+<programlisting>
+GRANT pg_signal_backend TO admin_user;
+</programlisting>
</para>
+ <warning>
+ <para>
+ Care should be taken when granting these roles to ensure they are only used
+ where needed and with the understanding that these roles grant access to
+ privileged information.
+ </para>
+ </warning>
+
<para>
- The predefined roles are described in <xref linkend="predefined-roles-table"/>.
+ The predefined roles are described below.
Note that the specific permissions for each of the roles may change in
the future as additional capabilities are added. Administrators
should monitor the release notes for changes.
- </para>
- <table tocentry="1" id="predefined-roles-table">
- <title>Predefined Roles</title>
- <tgroup cols="2">
- <colspec colname="col1" colwidth="1*"/>
- <colspec colname="col2" colwidth="2*"/>
- <thead>
- <row>
- <entry>Role</entry>
- <entry>Allowed Access</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>pg_read_all_data</entry>
- <entry>Read all data (tables, views, sequences), as if having
- <command>SELECT</command> rights on those objects, and USAGE rights on
- all schemas, even without having it explicitly. This role does not have
- the role attribute <literal>BYPASSRLS</literal> set. If RLS is being
- used, an administrator may wish to set <literal>BYPASSRLS</literal> on
- roles which this role is GRANTed to.</entry>
- </row>
- <row>
- <entry>pg_write_all_data</entry>
- <entry>Write all data (tables, views, sequences), as if having
- <command>INSERT</command>, <command>UPDATE</command>, and
- <command>DELETE</command> rights on those objects, and USAGE rights on
- all schemas, even without having it explicitly. This role does not have
- the role attribute <literal>BYPASSRLS</literal> set. If RLS is being
- used, an administrator may wish to set <literal>BYPASSRLS</literal> on
- roles which this role is GRANTed to.</entry>
- </row>
- <row>
- <entry>pg_read_all_settings</entry>
- <entry>Read all configuration variables, even those normally visible only to
- superusers.</entry>
- </row>
- <row>
- <entry>pg_read_all_stats</entry>
- <entry>Read all pg_stat_* views and use various statistics related extensions,
- even those normally visible only to superusers.</entry>
- </row>
- <row>
- <entry>pg_stat_scan_tables</entry>
- <entry>Execute monitoring functions that may take <literal>ACCESS SHARE</literal> locks on tables,
- potentially for a long time.</entry>
- </row>
- <row>
- <entry>pg_monitor</entry>
- <entry>Read/execute various monitoring views and functions.
- This role is a member of <literal>pg_read_all_settings</literal>,
- <literal>pg_read_all_stats</literal> and
- <literal>pg_stat_scan_tables</literal>.</entry>
- </row>
- <row>
- <entry>pg_database_owner</entry>
- <entry>None. Membership consists, implicitly, of the current database owner.</entry>
- </row>
- <row>
- <entry>pg_signal_backend</entry>
- <entry>Signal another backend to cancel a query or terminate its session.</entry>
- </row>
- <row>
- <entry>pg_read_server_files</entry>
- <entry>Allow reading files from any location the database can access on the server with COPY and
- other file-access functions.</entry>
- </row>
- <row>
- <entry>pg_write_server_files</entry>
- <entry>Allow writing to files in any location the database can access on the server with COPY and
- other file-access functions.</entry>
- </row>
- <row>
- <entry>pg_execute_server_program</entry>
- <entry>Allow executing programs on the database server as the user the database runs as with
- COPY and other functions which allow executing a server-side program.</entry>
- </row>
- <row>
- <entry>pg_checkpoint</entry>
- <entry>Allow executing
- the <link linkend="sql-checkpoint"><command>CHECKPOINT</command></link>
- command.</entry>
- </row>
- <row>
- <entry>pg_maintain</entry>
- <entry>Allow executing
+ <variablelist>
+ <varlistentry id="predefined-role-pg-checkpoint" xreflabel="pg_checkpoint">
+ <term><varname>pg_checkpoint</varname></term>
+ <listitem>
+ <para>
+ Allows executing the
+ <link linkend="sql-checkpoint"><command>CHECKPOINT</command></link> command.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-create-subscription" xreflabel="pg_create_subscription">
+ <term><varname>pg_create_subscription</varname></term>
+ <listitem>
+ <para>
+ Allows users with <literal>CREATE</literal> permission on the database to issue
+ <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-database-owner" xreflabel="pg_database_owner">
+ <term><varname>pg_database_owner</varname></term>
+ <listitem>
+ <para>
+ Membership consists, implicitly, of the current database owner. Like
+ any role, it can own objects or receive grants of access privileges.
+ Consequently, once <literal>pg_database_owner</literal> has rights
+ within a template database, each owner of a database instantiated from
+ that template will exercise those rights.
+ <literal>pg_database_owner</literal> cannot be a member of any role, and
+ it cannot have non-implicit members. Initially, this role owns the
+ <literal>public</literal> schema, so each database owner governs local
+ use of the schema.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-maintain" xreflabel="pg_maintain">
+ <term><varname>pg_maintain</varname></term>
+ <listitem>
+ <para>
+ Allows executing
<link linkend="sql-vacuum"><command>VACUUM</command></link>,
<link linkend="sql-analyze"><command>ANALYZE</command></link>,
<link linkend="sql-cluster"><command>CLUSTER</command></link>,
@@ -692,78 +662,129 @@ DROP ROLE doomed_role;
<link linkend="sql-reindex"><command>REINDEX</command></link>,
and <link linkend="sql-lock"><command>LOCK TABLE</command></link> on all
relations, as if having <literal>MAINTAIN</literal> rights on those
- objects, even without having it explicitly.</entry>
- </row>
- <row>
- <entry>pg_use_reserved_connections</entry>
- <entry>Allow use of connection slots reserved via
- <xref linkend="guc-reserved-connections"/>.</entry>
- </row>
- <row>
- <entry>pg_create_subscription</entry>
- <entry>Allow users with <literal>CREATE</literal> permission on the
- database to issue
- <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link>.</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- The <literal>pg_monitor</literal>, <literal>pg_read_all_settings</literal>,
- <literal>pg_read_all_stats</literal> and <literal>pg_stat_scan_tables</literal>
- roles are intended to allow administrators to easily configure a role for the
- purpose of monitoring the database server. They grant a set of common privileges
- allowing the role to read various useful configuration settings, statistics and
- other system information normally restricted to superusers.
- </para>
-
- <para>
- The <literal>pg_database_owner</literal> role has one implicit,
- situation-dependent member, namely the owner of the current database. Like
- any role, it can own objects or receive grants of access privileges.
- Consequently, once <literal>pg_database_owner</literal> has rights within a
- template database, each owner of a database instantiated from that template
- will exercise those rights. <literal>pg_database_owner</literal> cannot be
- a member of any role, and it cannot have non-implicit members. Initially,
- this role owns the <literal>public</literal> schema, so each database owner
- governs local use of the schema.
- </para>
-
- <para>
- The <literal>pg_signal_backend</literal> role is intended to allow
- administrators to enable trusted, but non-superuser, roles to send signals
- to other backends. Currently this role enables sending of signals for
- canceling a query on another backend or terminating its session. A user
- granted this role cannot however send signals to a backend owned by a
- superuser. See <xref linkend="functions-admin-signal"/>.
- </para>
-
- <para>
- The <literal>pg_read_server_files</literal>, <literal>pg_write_server_files</literal> and
- <literal>pg_execute_server_program</literal> roles are intended to allow administrators to have
- trusted, but non-superuser, roles which are able to access files and run programs on the
- database server as the user the database runs as. As these roles are able to access any file on
- the server file system, they bypass all database-level permission checks when accessing files
- directly and they could be used to gain superuser-level access, therefore
- great care should be taken when granting these roles to users.
- </para>
-
- <para>
- Care should be taken when granting these roles to ensure they are only used where
- needed and with the understanding that these roles grant access to privileged
- information.
- </para>
-
- <para>
- Administrators can grant access to these roles to users using the
- <link linkend="sql-grant"><command>GRANT</command></link> command, for example:
-
-<programlisting>
-GRANT pg_signal_backend TO admin_user;
-</programlisting>
+ objects, even without having it explicitly.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-read-all-data" xreflabel="pg_read_all_data">
+ <term><varname>pg_read_all_data</varname></term>
+ <term><varname>pg_write_all_data</varname></term>
+ <listitem>
+ <para>
+ <literal>pg_read_all_data</literal> allows reading all data (tables,
+ views, sequences), as if having <command>SELECT</command> rights on
+ those objects, and USAGE rights on all schemas, even without having it
+ explicitly. This role does not have the role attribute
+ <literal>BYPASSRLS</literal> set. If RLS is being used, an
+ administrator may wish to set <literal>BYPASSRLS</literal> on roles
+ which this role is GRANTed to.
+ </para>
+ <para>
+ <literal>pg_write_all_data</literal> allows writing all data (tables,
+ views, sequences), as if having <command>INSERT</command>,
+ <command>UPDATE</command>, and <command>DELETE</command> rights on those
+ objects, and USAGE rights on all schemas, even without having it
+ explicitly. This role does not have the role attribute
+ <literal>BYPASSRLS</literal> set. If RLS is being used, an
+ administrator may wish to set <literal>BYPASSRLS</literal> on roles
+ which this role is GRANTed to.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-read-all-settings" xreflabel="pg_read_all_settings">
+ <term><varname>pg_read_all_settings</varname></term>
+ <term><varname>pg_read_all_stats</varname></term>
+ <term><varname>pg_stat_scan_tables</varname></term>
+ <term><varname>pg_monitor</varname></term>
+ <listitem>
+ <para>
+ These roles are intended to allow administrators to easily configure a
+ role for the purpose of monitoring the database server. They grant a
+ set of common privileges allowing the role to read various useful
+ configuration settings, statistics, and other system information
+ normally restricted to superusers.
+ </para>
+ <para>
+ <literal>pg_read_all_settings</literal> allows reading all configuration
+ variables, even those normally visible only to superusers.
+ </para>
+ <para>
+ <literal>pg_read_all_stats</literal> allows reading all pg_stat_* views
+ and use various statistics related extensions, even those normally
+ visible only to superusers.
+ </para>
+ <para>
+ <literal>pg_stat_scan_tables</literal> allows executing monitoring
+ functions that may take <literal>ACCESS SHARE</literal> locks on tables,
+ potentially for a long time.
+ </para>
+ <para>
+ <literal>pg_monitor</literal> allows reading/executing various
+ monitoring views and functions. This role is a member of
+ <literal>pg_read_all_settings</literal>,
+ <literal>pg_read_all_stats</literal> and
+ <literal>pg_stat_scan_tables</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-read-server-files" xreflabel="pg_read_server_files">
+ <term><varname>pg_read_server_files</varname></term>
+ <term><varname>pg_write_server_files</varname></term>
+ <term><varname>pg_execute_server_program</varname></term>
+ <listitem>
+ <para>
+ These roles are intended to allow administrators to have trusted, but
+ non-superuser, roles which are able to access files and run programs on
+ the database server as the user the database runs as. As these roles
+ are able to access any file on the server file system, they bypass all
+ database-level permission checks when accessing files directly and they
+ could be used to gain superuser-level access, therefore great care
+ should be taken when granting these roles to users.
+ </para>
+ <para>
+ <literal>pg_read_server_files</literal> allows reading files from any
+ location the database can access on the server with COPY and other
+ file-access functions.
+ </para>
+ <para>
+ <literal>pg_write_server_files</literal> allows writing to files in any
+ location the database can access on the server with COPY any other
+ file-access functions.
+ </para>
+ <para>
+ <literal>pg_execute_server_program</literal> allows executing programs
+ on the database server as the user the database runs as with COPY and
+ other functions which allow executing a server-side program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-signal-backend" xreflabel="pg_signal_backend">
+ <term><varname>pg_signal_backend</varname></term>
+ <listitem>
+ <para>
+ Allows signaling another backend to cancel a query or terminate its
+ session. A user granted this role cannot however send signals to a
+ backend owned by a superuser. See
+ <xref linkend="functions-admin-signal"/>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-use-reserved-connections" xreflabel="pg_use_reserved_connections">
+ <term><varname>pg_use_reserved_connections</varname></term>
+ <listitem>
+ <para>
+ Allows use of connection slots reserved via
+ <xref linkend="guc-reserved-connections"/>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</para>
-
</sect1>
<sect1 id="perm-functions">
--
2.39.3 (Apple Git-146)
Attachments:
[text/plain] v1-0001-revamp-predefined-roles-documentation.patch (19.2K, ../../ZnG7PNN6BK32G_6B@nathan/2-v1-0001-revamp-predefined-roles-documentation.patch)
download | inline diff:
From 89db4a562ddb07aa1215608fb116b511143b0e66 Mon Sep 17 00:00:00 2001
From: Nathan Bossart <[email protected]>
Date: Tue, 18 Jun 2024 11:38:40 -0500
Subject: [PATCH v1 1/1] revamp predefined roles documentation
---
doc/src/sgml/config.sgml | 2 +-
doc/src/sgml/monitoring.sgml | 4 +-
doc/src/sgml/ref/checkpoint.sgml | 2 +-
doc/src/sgml/ref/reindex.sgml | 2 +-
doc/src/sgml/user-manag.sgml | 339 ++++++++++++++++---------------
5 files changed, 185 insertions(+), 164 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 698169afdb..b9fd3f3bd6 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -731,7 +731,7 @@ include_dir 'conf.d'
<para>
Determines the number of connection <quote>slots</quote> that are
reserved for connections by roles with privileges of the
- <link linkend="predefined-roles-table"><literal>pg_use_reserved_connections</literal></link>
+ <xref linkend="predefined-role-pg-use-reserved-connections"/>
role. Whenever the number of free connection slots is greater than
<xref linkend="guc-superuser-reserved-connections"/> but less than or
equal to the sum of <varname>superuser_reserved_connections</varname>
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index b2ad9b446f..133ad462cb 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -286,8 +286,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
other sessions, many columns will be null. Note, however, that the
existence of a session and its general properties such as its sessions user
and database are visible to all users. Superusers and roles with privileges of
- built-in role <literal>pg_read_all_stats</literal> (see also <xref
- linkend="predefined-roles"/>) can see all the information about all sessions.
+ built-in role <link linkend="predefined-role-pg-read-all-settings"><literal>pg_read_all_stats</literal></link>
+ can see all the information about all sessions.
</para>
<table id="monitoring-stats-dynamic-views-table">
diff --git a/doc/src/sgml/ref/checkpoint.sgml b/doc/src/sgml/ref/checkpoint.sgml
index 28a1d717b8..db011a47d0 100644
--- a/doc/src/sgml/ref/checkpoint.sgml
+++ b/doc/src/sgml/ref/checkpoint.sgml
@@ -53,7 +53,7 @@ CHECKPOINT
<para>
Only superusers or users with the privileges of
- the <link linkend="predefined-roles-table"><literal>pg_checkpoint</literal></link>
+ the <xref linkend="predefined-role-pg-checkpoint"/>
role can call <command>CHECKPOINT</command>.
</para>
</refsect1>
diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml
index 2942dccf1e..dcf70d14bc 100644
--- a/doc/src/sgml/ref/reindex.sgml
+++ b/doc/src/sgml/ref/reindex.sgml
@@ -305,7 +305,7 @@ REINDEX [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] { DA
partitioned table, such commands skip the privilege checks when processing
the individual partitions. Reindexing a schema or database requires being the
owner of that schema or database or having privileges of the
- <link linkend="predefined-roles-table"><literal>pg_maintain</literal></link>
+ <xref linkend="predefined-role-pg-maintain"/>
role. Note specifically that it's thus
possible for non-superusers to rebuild indexes of tables owned by
other users. However, as a special exception,
diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml
index 07a16247d7..1d3805d303 100644
--- a/doc/src/sgml/user-manag.sgml
+++ b/doc/src/sgml/user-manag.sgml
@@ -590,101 +590,71 @@ DROP ROLE doomed_role;
and information. Administrators (including roles that have the
<literal>CREATEROLE</literal> privilege) can <command>GRANT</command> these
roles to users and/or other roles in their environment, providing those
- users with access to the specified capabilities and information.
+ users with access to the specified capabilities and information. For
+ example:
+
+<programlisting>
+GRANT pg_signal_backend TO admin_user;
+</programlisting>
</para>
+ <warning>
+ <para>
+ Care should be taken when granting these roles to ensure they are only used
+ where needed and with the understanding that these roles grant access to
+ privileged information.
+ </para>
+ </warning>
+
<para>
- The predefined roles are described in <xref linkend="predefined-roles-table"/>.
+ The predefined roles are described below.
Note that the specific permissions for each of the roles may change in
the future as additional capabilities are added. Administrators
should monitor the release notes for changes.
- </para>
- <table tocentry="1" id="predefined-roles-table">
- <title>Predefined Roles</title>
- <tgroup cols="2">
- <colspec colname="col1" colwidth="1*"/>
- <colspec colname="col2" colwidth="2*"/>
- <thead>
- <row>
- <entry>Role</entry>
- <entry>Allowed Access</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>pg_read_all_data</entry>
- <entry>Read all data (tables, views, sequences), as if having
- <command>SELECT</command> rights on those objects, and USAGE rights on
- all schemas, even without having it explicitly. This role does not have
- the role attribute <literal>BYPASSRLS</literal> set. If RLS is being
- used, an administrator may wish to set <literal>BYPASSRLS</literal> on
- roles which this role is GRANTed to.</entry>
- </row>
- <row>
- <entry>pg_write_all_data</entry>
- <entry>Write all data (tables, views, sequences), as if having
- <command>INSERT</command>, <command>UPDATE</command>, and
- <command>DELETE</command> rights on those objects, and USAGE rights on
- all schemas, even without having it explicitly. This role does not have
- the role attribute <literal>BYPASSRLS</literal> set. If RLS is being
- used, an administrator may wish to set <literal>BYPASSRLS</literal> on
- roles which this role is GRANTed to.</entry>
- </row>
- <row>
- <entry>pg_read_all_settings</entry>
- <entry>Read all configuration variables, even those normally visible only to
- superusers.</entry>
- </row>
- <row>
- <entry>pg_read_all_stats</entry>
- <entry>Read all pg_stat_* views and use various statistics related extensions,
- even those normally visible only to superusers.</entry>
- </row>
- <row>
- <entry>pg_stat_scan_tables</entry>
- <entry>Execute monitoring functions that may take <literal>ACCESS SHARE</literal> locks on tables,
- potentially for a long time.</entry>
- </row>
- <row>
- <entry>pg_monitor</entry>
- <entry>Read/execute various monitoring views and functions.
- This role is a member of <literal>pg_read_all_settings</literal>,
- <literal>pg_read_all_stats</literal> and
- <literal>pg_stat_scan_tables</literal>.</entry>
- </row>
- <row>
- <entry>pg_database_owner</entry>
- <entry>None. Membership consists, implicitly, of the current database owner.</entry>
- </row>
- <row>
- <entry>pg_signal_backend</entry>
- <entry>Signal another backend to cancel a query or terminate its session.</entry>
- </row>
- <row>
- <entry>pg_read_server_files</entry>
- <entry>Allow reading files from any location the database can access on the server with COPY and
- other file-access functions.</entry>
- </row>
- <row>
- <entry>pg_write_server_files</entry>
- <entry>Allow writing to files in any location the database can access on the server with COPY and
- other file-access functions.</entry>
- </row>
- <row>
- <entry>pg_execute_server_program</entry>
- <entry>Allow executing programs on the database server as the user the database runs as with
- COPY and other functions which allow executing a server-side program.</entry>
- </row>
- <row>
- <entry>pg_checkpoint</entry>
- <entry>Allow executing
- the <link linkend="sql-checkpoint"><command>CHECKPOINT</command></link>
- command.</entry>
- </row>
- <row>
- <entry>pg_maintain</entry>
- <entry>Allow executing
+ <variablelist>
+ <varlistentry id="predefined-role-pg-checkpoint" xreflabel="pg_checkpoint">
+ <term><varname>pg_checkpoint</varname></term>
+ <listitem>
+ <para>
+ Allows executing the
+ <link linkend="sql-checkpoint"><command>CHECKPOINT</command></link> command.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-create-subscription" xreflabel="pg_create_subscription">
+ <term><varname>pg_create_subscription</varname></term>
+ <listitem>
+ <para>
+ Allows users with <literal>CREATE</literal> permission on the database to issue
+ <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-database-owner" xreflabel="pg_database_owner">
+ <term><varname>pg_database_owner</varname></term>
+ <listitem>
+ <para>
+ Membership consists, implicitly, of the current database owner. Like
+ any role, it can own objects or receive grants of access privileges.
+ Consequently, once <literal>pg_database_owner</literal> has rights
+ within a template database, each owner of a database instantiated from
+ that template will exercise those rights.
+ <literal>pg_database_owner</literal> cannot be a member of any role, and
+ it cannot have non-implicit members. Initially, this role owns the
+ <literal>public</literal> schema, so each database owner governs local
+ use of the schema.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-maintain" xreflabel="pg_maintain">
+ <term><varname>pg_maintain</varname></term>
+ <listitem>
+ <para>
+ Allows executing
<link linkend="sql-vacuum"><command>VACUUM</command></link>,
<link linkend="sql-analyze"><command>ANALYZE</command></link>,
<link linkend="sql-cluster"><command>CLUSTER</command></link>,
@@ -692,78 +662,129 @@ DROP ROLE doomed_role;
<link linkend="sql-reindex"><command>REINDEX</command></link>,
and <link linkend="sql-lock"><command>LOCK TABLE</command></link> on all
relations, as if having <literal>MAINTAIN</literal> rights on those
- objects, even without having it explicitly.</entry>
- </row>
- <row>
- <entry>pg_use_reserved_connections</entry>
- <entry>Allow use of connection slots reserved via
- <xref linkend="guc-reserved-connections"/>.</entry>
- </row>
- <row>
- <entry>pg_create_subscription</entry>
- <entry>Allow users with <literal>CREATE</literal> permission on the
- database to issue
- <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link>.</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- The <literal>pg_monitor</literal>, <literal>pg_read_all_settings</literal>,
- <literal>pg_read_all_stats</literal> and <literal>pg_stat_scan_tables</literal>
- roles are intended to allow administrators to easily configure a role for the
- purpose of monitoring the database server. They grant a set of common privileges
- allowing the role to read various useful configuration settings, statistics and
- other system information normally restricted to superusers.
- </para>
-
- <para>
- The <literal>pg_database_owner</literal> role has one implicit,
- situation-dependent member, namely the owner of the current database. Like
- any role, it can own objects or receive grants of access privileges.
- Consequently, once <literal>pg_database_owner</literal> has rights within a
- template database, each owner of a database instantiated from that template
- will exercise those rights. <literal>pg_database_owner</literal> cannot be
- a member of any role, and it cannot have non-implicit members. Initially,
- this role owns the <literal>public</literal> schema, so each database owner
- governs local use of the schema.
- </para>
-
- <para>
- The <literal>pg_signal_backend</literal> role is intended to allow
- administrators to enable trusted, but non-superuser, roles to send signals
- to other backends. Currently this role enables sending of signals for
- canceling a query on another backend or terminating its session. A user
- granted this role cannot however send signals to a backend owned by a
- superuser. See <xref linkend="functions-admin-signal"/>.
- </para>
-
- <para>
- The <literal>pg_read_server_files</literal>, <literal>pg_write_server_files</literal> and
- <literal>pg_execute_server_program</literal> roles are intended to allow administrators to have
- trusted, but non-superuser, roles which are able to access files and run programs on the
- database server as the user the database runs as. As these roles are able to access any file on
- the server file system, they bypass all database-level permission checks when accessing files
- directly and they could be used to gain superuser-level access, therefore
- great care should be taken when granting these roles to users.
- </para>
-
- <para>
- Care should be taken when granting these roles to ensure they are only used where
- needed and with the understanding that these roles grant access to privileged
- information.
- </para>
-
- <para>
- Administrators can grant access to these roles to users using the
- <link linkend="sql-grant"><command>GRANT</command></link> command, for example:
-
-<programlisting>
-GRANT pg_signal_backend TO admin_user;
-</programlisting>
+ objects, even without having it explicitly.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-read-all-data" xreflabel="pg_read_all_data">
+ <term><varname>pg_read_all_data</varname></term>
+ <term><varname>pg_write_all_data</varname></term>
+ <listitem>
+ <para>
+ <literal>pg_read_all_data</literal> allows reading all data (tables,
+ views, sequences), as if having <command>SELECT</command> rights on
+ those objects, and USAGE rights on all schemas, even without having it
+ explicitly. This role does not have the role attribute
+ <literal>BYPASSRLS</literal> set. If RLS is being used, an
+ administrator may wish to set <literal>BYPASSRLS</literal> on roles
+ which this role is GRANTed to.
+ </para>
+ <para>
+ <literal>pg_write_all_data</literal> allows writing all data (tables,
+ views, sequences), as if having <command>INSERT</command>,
+ <command>UPDATE</command>, and <command>DELETE</command> rights on those
+ objects, and USAGE rights on all schemas, even without having it
+ explicitly. This role does not have the role attribute
+ <literal>BYPASSRLS</literal> set. If RLS is being used, an
+ administrator may wish to set <literal>BYPASSRLS</literal> on roles
+ which this role is GRANTed to.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-read-all-settings" xreflabel="pg_read_all_settings">
+ <term><varname>pg_read_all_settings</varname></term>
+ <term><varname>pg_read_all_stats</varname></term>
+ <term><varname>pg_stat_scan_tables</varname></term>
+ <term><varname>pg_monitor</varname></term>
+ <listitem>
+ <para>
+ These roles are intended to allow administrators to easily configure a
+ role for the purpose of monitoring the database server. They grant a
+ set of common privileges allowing the role to read various useful
+ configuration settings, statistics, and other system information
+ normally restricted to superusers.
+ </para>
+ <para>
+ <literal>pg_read_all_settings</literal> allows reading all configuration
+ variables, even those normally visible only to superusers.
+ </para>
+ <para>
+ <literal>pg_read_all_stats</literal> allows reading all pg_stat_* views
+ and use various statistics related extensions, even those normally
+ visible only to superusers.
+ </para>
+ <para>
+ <literal>pg_stat_scan_tables</literal> allows executing monitoring
+ functions that may take <literal>ACCESS SHARE</literal> locks on tables,
+ potentially for a long time.
+ </para>
+ <para>
+ <literal>pg_monitor</literal> allows reading/executing various
+ monitoring views and functions. This role is a member of
+ <literal>pg_read_all_settings</literal>,
+ <literal>pg_read_all_stats</literal> and
+ <literal>pg_stat_scan_tables</literal>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-read-server-files" xreflabel="pg_read_server_files">
+ <term><varname>pg_read_server_files</varname></term>
+ <term><varname>pg_write_server_files</varname></term>
+ <term><varname>pg_execute_server_program</varname></term>
+ <listitem>
+ <para>
+ These roles are intended to allow administrators to have trusted, but
+ non-superuser, roles which are able to access files and run programs on
+ the database server as the user the database runs as. As these roles
+ are able to access any file on the server file system, they bypass all
+ database-level permission checks when accessing files directly and they
+ could be used to gain superuser-level access, therefore great care
+ should be taken when granting these roles to users.
+ </para>
+ <para>
+ <literal>pg_read_server_files</literal> allows reading files from any
+ location the database can access on the server with COPY and other
+ file-access functions.
+ </para>
+ <para>
+ <literal>pg_write_server_files</literal> allows writing to files in any
+ location the database can access on the server with COPY any other
+ file-access functions.
+ </para>
+ <para>
+ <literal>pg_execute_server_program</literal> allows executing programs
+ on the database server as the user the database runs as with COPY and
+ other functions which allow executing a server-side program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-signal-backend" xreflabel="pg_signal_backend">
+ <term><varname>pg_signal_backend</varname></term>
+ <listitem>
+ <para>
+ Allows signaling another backend to cancel a query or terminate its
+ session. A user granted this role cannot however send signals to a
+ backend owned by a superuser. See
+ <xref linkend="functions-admin-signal"/>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-use-reserved-connections" xreflabel="pg_use_reserved_connections">
+ <term><varname>pg_use_reserved_connections</varname></term>
+ <listitem>
+ <para>
+ Allows use of connection slots reserved via
+ <xref linkend="guc-reserved-connections"/>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</para>
-
</sect1>
<sect1 id="perm-functions">
--
2.39.3 (Apple Git-146)
[text/html] predefined-roles.html (11.7K, ../../ZnG7PNN6BK32G_6B@nathan/3-predefined-roles.html)
download | inline:
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>21.5. Predefined Roles</title><link rel="stylesheet" type="text/css" href="https://www.postgresql.org/media/css/docs-complete.css" /><link rev="made" href="[email protected]" /><meta name="generator" content="DocBook XSL Stylesheets Vsnapshot" /><link rel="prev" href="role-removal.html" title="21.4. Dropping Roles" /><link rel="next" href="perm-functions.html" title="21.6. Function Security" /></head><body id="docContent" class="container-fluid col-10"><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">21.5. Predefined Roles</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="role-removal.html" title="21.4. Dropping Roles">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="user-manag.html" title="Chapter 21. Database Roles">Up</a></td><th width="60%" align="center">Chapter 21. Database Roles</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 17beta1 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="perm-functions.html" title="21.6. Function Security">Next</a></td></tr></table><hr /></div><div class="sect1" id="PREDEFINED-ROLES"><div class="titlepage"><div><div><h2 class="title" style="clear: both">21.5. Predefined Roles <a href="#PREDEFINED-ROLES" class="id_link">#</a></h2></div></div></div><a id="id-1.6.8.9.2" class="indexterm"></a><p>
<span class="productname">PostgreSQL</span> provides a set of predefined roles
that provide access to certain, commonly needed, privileged capabilities
and information. Administrators (including roles that have the
<code class="literal">CREATEROLE</code> privilege) can <code class="command">GRANT</code> these
roles to users and/or other roles in their environment, providing those
users with access to the specified capabilities and information. For
example:
</p><pre class="programlisting">
GRANT pg_signal_backend TO admin_user;
</pre><p>
</p><div class="warning"><h3 class="title">Warning</h3><p>
Care should be taken when granting these roles to ensure they are only used
where needed and with the understanding that these roles grant access to
privileged information.
</p></div><p>
The predefined roles are described below.
Note that the specific permissions for each of the roles may change in
the future as additional capabilities are added. Administrators
should monitor the release notes for changes.
</p><div class="variablelist"><dl class="variablelist"><dt id="PREDEFINED-ROLE-PG-CHECKPOINT"><span class="term"><code class="varname">pg_checkpoint</code></span> <a href="#PREDEFINED-ROLE-PG-CHECKPOINT" class="id_link">#</a></dt><dd><p>
Allows executing the
<a class="link" href="sql-checkpoint.html" title="CHECKPOINT"><code class="command">CHECKPOINT</code></a> command.
</p></dd><dt id="PREDEFINED-ROLE-PG-CREATE-SUBSCRIPTION"><span class="term"><code class="varname">pg_create_subscription</code></span> <a href="#PREDEFINED-ROLE-PG-CREATE-SUBSCRIPTION" class="id_link">#</a></dt><dd><p>
Allows users with <code class="literal">CREATE</code> permission on the database to issue
<a class="link" href="sql-createsubscription.html" title="CREATE SUBSCRIPTION"><code class="command">CREATE SUBSCRIPTION</code></a>.
</p></dd><dt id="PREDEFINED-ROLE-PG-DATABASE-OWNER"><span class="term"><code class="varname">pg_database_owner</code></span> <a href="#PREDEFINED-ROLE-PG-DATABASE-OWNER" class="id_link">#</a></dt><dd><p>
Membership consists, implicitly, of the current database owner. Like
any role, it can own objects or receive grants of access privileges.
Consequently, once <code class="literal">pg_database_owner</code> has rights
within a template database, each owner of a database instantiated from
that template will exercise those rights.
<code class="literal">pg_database_owner</code> cannot be a member of any role, and
it cannot have non-implicit members. Initially, this role owns the
<code class="literal">public</code> schema, so each database owner governs local
use of the schema.
</p></dd><dt id="PREDEFINED-ROLE-PG-MAINTAIN"><span class="term"><code class="varname">pg_maintain</code></span> <a href="#PREDEFINED-ROLE-PG-MAINTAIN" class="id_link">#</a></dt><dd><p>
Allows executing
<a class="link" href="sql-vacuum.html" title="VACUUM"><code class="command">VACUUM</code></a>,
<a class="link" href="sql-analyze.html" title="ANALYZE"><code class="command">ANALYZE</code></a>,
<a class="link" href="sql-cluster.html" title="CLUSTER"><code class="command">CLUSTER</code></a>,
<a class="link" href="sql-refreshmaterializedview.html" title="REFRESH MATERIALIZED VIEW"><code class="command">REFRESH MATERIALIZED VIEW</code></a>,
<a class="link" href="sql-reindex.html" title="REINDEX"><code class="command">REINDEX</code></a>,
and <a class="link" href="sql-lock.html" title="LOCK"><code class="command">LOCK TABLE</code></a> on all
relations, as if having <code class="literal">MAINTAIN</code> rights on those
objects, even without having it explicitly.
</p></dd><dt id="PREDEFINED-ROLE-PG-READ-ALL-DATA"><span class="term"><code class="varname">pg_read_all_data</code><br /></span><span class="term"><code class="varname">pg_write_all_data</code></span> <a href="#PREDEFINED-ROLE-PG-READ-ALL-DATA" class="id_link">#</a></dt><dd><p>
<code class="literal">pg_read_all_data</code> allows reading all data (tables,
views, sequences), as if having <code class="command">SELECT</code> rights on
those objects, and USAGE rights on all schemas, even without having it
explicitly. This role does not have the role attribute
<code class="literal">BYPASSRLS</code> set. If RLS is being used, an
administrator may wish to set <code class="literal">BYPASSRLS</code> on roles
which this role is GRANTed to.
</p><p>
<code class="literal">pg_write_all_data</code> allows writing all data (tables,
views, sequences), as if having <code class="command">INSERT</code>,
<code class="command">UPDATE</code>, and <code class="command">DELETE</code> rights on those
objects, and USAGE rights on all schemas, even without having it
explicitly. This role does not have the role attribute
<code class="literal">BYPASSRLS</code> set. If RLS is being used, an
administrator may wish to set <code class="literal">BYPASSRLS</code> on roles
which this role is GRANTed to.
</p></dd><dt id="PREDEFINED-ROLE-PG-READ-ALL-SETTINGS"><span class="term"><code class="varname">pg_read_all_settings</code><br /></span><span class="term"><code class="varname">pg_read_all_stats</code><br /></span><span class="term"><code class="varname">pg_stat_scan_tables</code><br /></span><span class="term"><code class="varname">pg_monitor</code></span> <a href="#PREDEFINED-ROLE-PG-READ-ALL-SETTINGS" class="id_link">#</a></dt><dd><p>
These roles are intended to allow administrators to easily configure a
role for the purpose of monitoring the database server. They grant a
set of common privileges allowing the role to read various useful
configuration settings, statistics, and other system information
normally restricted to superusers.
</p><p>
<code class="literal">pg_read_all_settings</code> allows reading all configuration
variables, even those normally visible only to superusers.
</p><p>
<code class="literal">pg_read_all_stats</code> allows reading all pg_stat_* views
and use various statistics related extensions, even those normally
visible only to superusers.
</p><p>
<code class="literal">pg_stat_scan_tables</code> allows executing monitoring
functions that may take <code class="literal">ACCESS SHARE</code> locks on tables,
potentially for a long time.
</p><p>
<code class="literal">pg_monitor</code> allows reading/executing various
monitoring views and functions. This role is a member of
<code class="literal">pg_read_all_settings</code>,
<code class="literal">pg_read_all_stats</code> and
<code class="literal">pg_stat_scan_tables</code>.
</p></dd><dt id="PREDEFINED-ROLE-PG-READ-SERVER-FILES"><span class="term"><code class="varname">pg_read_server_files</code><br /></span><span class="term"><code class="varname">pg_write_server_files</code><br /></span><span class="term"><code class="varname">pg_execute_server_program</code></span> <a href="#PREDEFINED-ROLE-PG-READ-SERVER-FILES" class="id_link">#</a></dt><dd><p>
These roles are intended to allow administrators to have trusted, but
non-superuser, roles which are able to access files and run programs on
the database server as the user the database runs as. As these roles
are able to access any file on the server file system, they bypass all
database-level permission checks when accessing files directly and they
could be used to gain superuser-level access, therefore great care
should be taken when granting these roles to users.
</p><p>
<code class="literal">pg_read_server_files</code> allows reading files from any
location the database can access on the server with COPY and other
file-access functions.
</p><p>
<code class="literal">pg_write_server_files</code> allows writing to files in any
location the database can access on the server with COPY any other
file-access functions.
</p><p>
<code class="literal">pg_execute_server_program</code> allows executing programs
on the database server as the user the database runs as with COPY and
other functions which allow executing a server-side program.
</p></dd><dt id="PREDEFINED-ROLE-PG-SIGNAL-BACKEND"><span class="term"><code class="varname">pg_signal_backend</code></span> <a href="#PREDEFINED-ROLE-PG-SIGNAL-BACKEND" class="id_link">#</a></dt><dd><p>
Allows signaling another backend to cancel a query or terminate its
session. A user granted this role cannot however send signals to a
backend owned by a superuser. See
<a class="xref" href="functions-admin.html#FUNCTIONS-ADMIN-SIGNAL" title="9.28.2. Server Signaling Functions">Section 9.28.2</a>.
</p></dd><dt id="PREDEFINED-ROLE-PG-USE-RESERVED-CONNECTIONS"><span class="term"><code class="varname">pg_use_reserved_connections</code></span> <a href="#PREDEFINED-ROLE-PG-USE-RESERVED-CONNECTIONS" class="id_link">#</a></dt><dd><p>
Allows use of connection slots reserved via
<a class="xref" href="runtime-config-connection.html#GUC-RESERVED-CONNECTIONS">reserved_connections</a>.
</p></dd></dl></div><p>
</p></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="role-removal.html" title="21.4. Dropping Roles">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="user-manag.html" title="Chapter 21. Database Roles">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="perm-functions.html" title="21.6. Function Security">Next</a></td></tr><tr><td width="40%" align="left" valign="top">21.4. Dropping Roles </td><td width="20%" align="center"><a accesskey="h" href="index.html" title="PostgreSQL 17beta1 Documentation">Home</a></td><td width="40%" align="right" valign="top"> 21.6. Function Security</td></tr></table></div></body></html>
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: improve predefined roles documentation
2024-06-13 19:48 improve predefined roles documentation Nathan Bossart <[email protected]>
2024-06-17 18:10 ` Re: improve predefined roles documentation Robert Haas <[email protected]>
2024-06-18 16:52 ` Re: improve predefined roles documentation Nathan Bossart <[email protected]>
@ 2024-06-21 02:57 ` David G. Johnston <[email protected]>
2024-06-21 15:40 ` Re: improve predefined roles documentation Nathan Bossart <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: David G. Johnston @ 2024-06-21 02:57 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: Robert Haas <[email protected]>; pgsql-hackers
On Tue, Jun 18, 2024 at 9:52 AM Nathan Bossart <[email protected]>
wrote:
> On Mon, Jun 17, 2024 at 02:10:22PM -0400, Robert Haas wrote:
> > On Thu, Jun 13, 2024 at 3:48 PM Nathan Bossart <[email protected]>
> wrote:
> >> I think we could improve matters by abandoning the table and instead
> >> documenting these roles more like we document GUCs, i.e., each one has a
> >> section below it where we can document it in as much detail as we want.
> >> Some of these roles should probably be documented together (e.g.,
> >> pg_read_all_data and pg_write_all_data), so the ordering is unlikely to
> be
> >> perfect, but I'm hoping it would still be a net improvement.
> >
> > +1. I'm not sure about all of the details, but I like the general idea.
>
> Here is a first try. I did pretty much exactly what I proposed in the
> quoted text, so I don't have much else to say about it. I didn't see an
> easy way to specify multiple ids and xreflabels for a given entry, so the
> entries that describe multiple roles just use the name of the first role
> listed. In practice, I think this just means you need to do a little extra
> work when linking to one of the other roles from elsewhere in the docs,
> which doesn't seem too terrible.
>
>
I like this. Losing the table turned out to be ok. Thank you.
I would probably put pg_monitor first in the list.
+ A user granted this role cannot however send signals to a backend owned
by a superuser.
Remove "however", or put commas around it. I prefer the first option.
Do we really need to repeat "even without having it explicitly" everywhere?
+ This role does not have the role attribute BYPASSRLS set.
Even if it did, that attribute isn't inherited anyway...
"This role is still governed by any row level security policies that may be
in force. Consider setting the BYPASSRLS attribute on member roles."
(assuming they intend it to be ALL data then doing the bypassrls even if
they are not today using it doesn't hurt)
pg_stat_scan_tables - This explanation leaves me wanting more. Maybe give
an example of such a function? I think the bar is set a bit too high just
talking about a specific lock level.
"As these roles are able to access any file on the server file system,"
We forbid running under root so this isn't really true. They do have
operating system level access logged in as the database process owner.
They are able to access all PostgreSQL files on the server file system and
usually can run a wide-variety of commands on the server.
"access, therefore great care should be taken"
I would go with:
"access. Great care should be taken"
Seems more impactful as its own sentence then at the end of a long
multi-part sentence.
"server with COPY any other file-access functions." - s/with/using/
David J.
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: improve predefined roles documentation
2024-06-13 19:48 improve predefined roles documentation Nathan Bossart <[email protected]>
2024-06-17 18:10 ` Re: improve predefined roles documentation Robert Haas <[email protected]>
2024-06-18 16:52 ` Re: improve predefined roles documentation Nathan Bossart <[email protected]>
2024-06-21 02:57 ` Re: improve predefined roles documentation David G. Johnston <[email protected]>
@ 2024-06-21 15:40 ` Nathan Bossart <[email protected]>
2024-06-24 18:44 ` Re: improve predefined roles documentation Robert Haas <[email protected]>
0 siblings, 1 reply; 9+ messages in thread
From: Nathan Bossart @ 2024-06-21 15:40 UTC (permalink / raw)
To: David G. Johnston <[email protected]>; +Cc: Robert Haas <[email protected]>; pgsql-hackers
On Thu, Jun 20, 2024 at 07:57:16PM -0700, David G. Johnston wrote:
> I like this. Losing the table turned out to be ok. Thank you.
Awesome.
> I would probably put pg_monitor first in the list.
Done.
> + A user granted this role cannot however send signals to a backend owned
> by a superuser.
>
> Remove "however", or put commas around it. I prefer the first option.
This sentence caught my eye earlier, too, because it seems to imply that a
superuser granted this role cannot signal superuser-owned backends. I
changed it to the following:
Note that this role does not permit signaling backends owned by a
superuser.
How does that sound?
> Do we really need to repeat "even without having it explicitly" everywhere?
Removed.
> + This role does not have the role attribute BYPASSRLS set.
>
> Even if it did, that attribute isn't inherited anyway...
>
> "This role is still governed by any row level security policies that may be
> in force. Consider setting the BYPASSRLS attribute on member roles."
>
> (assuming they intend it to be ALL data then doing the bypassrls even if
> they are not today using it doesn't hurt)
How does something like the following sound?
This role does not bypass row-level security (RLS) policies. If RLS is
being used, an administrator may wish to set BYPASSRLS on roles which
this role is granted to.
> pg_stat_scan_tables - This explanation leaves me wanting more. Maybe give
> an example of such a function? I think the bar is set a bit too high just
> talking about a specific lock level.
I was surprised to learn that this role only provides privileges for
functions in contrib/ modules. Anyway, added an example.
> "As these roles are able to access any file on the server file system,"
>
> We forbid running under root so this isn't really true. They do have
> operating system level access logged in as the database process owner.
> They are able to access all PostgreSQL files on the server file system and
> usually can run a wide-variety of commands on the server.
I just deleted this clause.
> "access, therefore great care should be taken"
>
> I would go with:
>
> "access. Great care should be taken"
>
> Seems more impactful as its own sentence then at the end of a long
> multi-part sentence.
Done.
> "server with COPY any other file-access functions." - s/with/using/
Done.
--
nathan
From 70ae4e75e59fb369bb46fccb579b9dedc6c24b11 Mon Sep 17 00:00:00 2001
From: Nathan Bossart <[email protected]>
Date: Tue, 18 Jun 2024 11:38:40 -0500
Subject: [PATCH v2 1/1] revamp predefined roles documentation
---
doc/src/sgml/config.sgml | 2 +-
doc/src/sgml/monitoring.sgml | 4 +-
doc/src/sgml/ref/checkpoint.sgml | 2 +-
doc/src/sgml/ref/reindex.sgml | 2 +-
doc/src/sgml/user-manag.sgml | 337 ++++++++++++++++---------------
5 files changed, 183 insertions(+), 164 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 0c7a9082c5..03e37209e6 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -731,7 +731,7 @@ include_dir 'conf.d'
<para>
Determines the number of connection <quote>slots</quote> that are
reserved for connections by roles with privileges of the
- <link linkend="predefined-roles-table"><literal>pg_use_reserved_connections</literal></link>
+ <xref linkend="predefined-role-pg-use-reserved-connections"/>
role. Whenever the number of free connection slots is greater than
<xref linkend="guc-superuser-reserved-connections"/> but less than or
equal to the sum of <varname>superuser_reserved_connections</varname>
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index b2ad9b446f..f30c1e53fa 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -286,8 +286,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
other sessions, many columns will be null. Note, however, that the
existence of a session and its general properties such as its sessions user
and database are visible to all users. Superusers and roles with privileges of
- built-in role <literal>pg_read_all_stats</literal> (see also <xref
- linkend="predefined-roles"/>) can see all the information about all sessions.
+ built-in role <link linkend="predefined-role-pg-monitor"><literal>pg_read_all_stats</literal></link>
+ can see all the information about all sessions.
</para>
<table id="monitoring-stats-dynamic-views-table">
diff --git a/doc/src/sgml/ref/checkpoint.sgml b/doc/src/sgml/ref/checkpoint.sgml
index 28a1d717b8..db011a47d0 100644
--- a/doc/src/sgml/ref/checkpoint.sgml
+++ b/doc/src/sgml/ref/checkpoint.sgml
@@ -53,7 +53,7 @@ CHECKPOINT
<para>
Only superusers or users with the privileges of
- the <link linkend="predefined-roles-table"><literal>pg_checkpoint</literal></link>
+ the <xref linkend="predefined-role-pg-checkpoint"/>
role can call <command>CHECKPOINT</command>.
</para>
</refsect1>
diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml
index 2942dccf1e..dcf70d14bc 100644
--- a/doc/src/sgml/ref/reindex.sgml
+++ b/doc/src/sgml/ref/reindex.sgml
@@ -305,7 +305,7 @@ REINDEX [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] { DA
partitioned table, such commands skip the privilege checks when processing
the individual partitions. Reindexing a schema or database requires being the
owner of that schema or database or having privileges of the
- <link linkend="predefined-roles-table"><literal>pg_maintain</literal></link>
+ <xref linkend="predefined-role-pg-maintain"/>
role. Note specifically that it's thus
possible for non-superusers to rebuild indexes of tables owned by
other users. However, as a special exception,
diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml
index 07a16247d7..aa37823be2 100644
--- a/doc/src/sgml/user-manag.sgml
+++ b/doc/src/sgml/user-manag.sgml
@@ -590,101 +590,71 @@ DROP ROLE doomed_role;
and information. Administrators (including roles that have the
<literal>CREATEROLE</literal> privilege) can <command>GRANT</command> these
roles to users and/or other roles in their environment, providing those
- users with access to the specified capabilities and information.
+ users with access to the specified capabilities and information. For
+ example:
+
+<programlisting>
+GRANT pg_signal_backend TO admin_user;
+</programlisting>
</para>
+ <warning>
+ <para>
+ Care should be taken when granting these roles to ensure they are only used
+ where needed and with the understanding that these roles grant access to
+ privileged information.
+ </para>
+ </warning>
+
<para>
- The predefined roles are described in <xref linkend="predefined-roles-table"/>.
+ The predefined roles are described below.
Note that the specific permissions for each of the roles may change in
the future as additional capabilities are added. Administrators
should monitor the release notes for changes.
- </para>
- <table tocentry="1" id="predefined-roles-table">
- <title>Predefined Roles</title>
- <tgroup cols="2">
- <colspec colname="col1" colwidth="1*"/>
- <colspec colname="col2" colwidth="2*"/>
- <thead>
- <row>
- <entry>Role</entry>
- <entry>Allowed Access</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>pg_read_all_data</entry>
- <entry>Read all data (tables, views, sequences), as if having
- <command>SELECT</command> rights on those objects, and USAGE rights on
- all schemas, even without having it explicitly. This role does not have
- the role attribute <literal>BYPASSRLS</literal> set. If RLS is being
- used, an administrator may wish to set <literal>BYPASSRLS</literal> on
- roles which this role is GRANTed to.</entry>
- </row>
- <row>
- <entry>pg_write_all_data</entry>
- <entry>Write all data (tables, views, sequences), as if having
- <command>INSERT</command>, <command>UPDATE</command>, and
- <command>DELETE</command> rights on those objects, and USAGE rights on
- all schemas, even without having it explicitly. This role does not have
- the role attribute <literal>BYPASSRLS</literal> set. If RLS is being
- used, an administrator may wish to set <literal>BYPASSRLS</literal> on
- roles which this role is GRANTed to.</entry>
- </row>
- <row>
- <entry>pg_read_all_settings</entry>
- <entry>Read all configuration variables, even those normally visible only to
- superusers.</entry>
- </row>
- <row>
- <entry>pg_read_all_stats</entry>
- <entry>Read all pg_stat_* views and use various statistics related extensions,
- even those normally visible only to superusers.</entry>
- </row>
- <row>
- <entry>pg_stat_scan_tables</entry>
- <entry>Execute monitoring functions that may take <literal>ACCESS SHARE</literal> locks on tables,
- potentially for a long time.</entry>
- </row>
- <row>
- <entry>pg_monitor</entry>
- <entry>Read/execute various monitoring views and functions.
- This role is a member of <literal>pg_read_all_settings</literal>,
- <literal>pg_read_all_stats</literal> and
- <literal>pg_stat_scan_tables</literal>.</entry>
- </row>
- <row>
- <entry>pg_database_owner</entry>
- <entry>None. Membership consists, implicitly, of the current database owner.</entry>
- </row>
- <row>
- <entry>pg_signal_backend</entry>
- <entry>Signal another backend to cancel a query or terminate its session.</entry>
- </row>
- <row>
- <entry>pg_read_server_files</entry>
- <entry>Allow reading files from any location the database can access on the server with COPY and
- other file-access functions.</entry>
- </row>
- <row>
- <entry>pg_write_server_files</entry>
- <entry>Allow writing to files in any location the database can access on the server with COPY and
- other file-access functions.</entry>
- </row>
- <row>
- <entry>pg_execute_server_program</entry>
- <entry>Allow executing programs on the database server as the user the database runs as with
- COPY and other functions which allow executing a server-side program.</entry>
- </row>
- <row>
- <entry>pg_checkpoint</entry>
- <entry>Allow executing
- the <link linkend="sql-checkpoint"><command>CHECKPOINT</command></link>
- command.</entry>
- </row>
- <row>
- <entry>pg_maintain</entry>
- <entry>Allow executing
+ <variablelist>
+ <varlistentry id="predefined-role-pg-checkpoint" xreflabel="pg_checkpoint">
+ <term><varname>pg_checkpoint</varname></term>
+ <listitem>
+ <para>
+ Allows executing the
+ <link linkend="sql-checkpoint"><command>CHECKPOINT</command></link> command.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-create-subscription" xreflabel="pg_create_subscription">
+ <term><varname>pg_create_subscription</varname></term>
+ <listitem>
+ <para>
+ Allows users with <literal>CREATE</literal> permission on the database to issue
+ <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-database-owner" xreflabel="pg_database_owner">
+ <term><varname>pg_database_owner</varname></term>
+ <listitem>
+ <para>
+ Membership consists, implicitly, of the current database owner. Like
+ any role, it can own objects or receive grants of access privileges.
+ Consequently, once <literal>pg_database_owner</literal> has rights
+ within a template database, each owner of a database instantiated from
+ that template will exercise those rights.
+ <literal>pg_database_owner</literal> cannot be a member of any role, and
+ it cannot have non-implicit members. Initially, this role owns the
+ <literal>public</literal> schema, so each database owner governs local
+ use of the schema.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-maintain" xreflabel="pg_maintain">
+ <term><varname>pg_maintain</varname></term>
+ <listitem>
+ <para>
+ Allows executing
<link linkend="sql-vacuum"><command>VACUUM</command></link>,
<link linkend="sql-analyze"><command>ANALYZE</command></link>,
<link linkend="sql-cluster"><command>CLUSTER</command></link>,
@@ -692,78 +662,127 @@ DROP ROLE doomed_role;
<link linkend="sql-reindex"><command>REINDEX</command></link>,
and <link linkend="sql-lock"><command>LOCK TABLE</command></link> on all
relations, as if having <literal>MAINTAIN</literal> rights on those
- objects, even without having it explicitly.</entry>
- </row>
- <row>
- <entry>pg_use_reserved_connections</entry>
- <entry>Allow use of connection slots reserved via
- <xref linkend="guc-reserved-connections"/>.</entry>
- </row>
- <row>
- <entry>pg_create_subscription</entry>
- <entry>Allow users with <literal>CREATE</literal> permission on the
- database to issue
- <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link>.</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- The <literal>pg_monitor</literal>, <literal>pg_read_all_settings</literal>,
- <literal>pg_read_all_stats</literal> and <literal>pg_stat_scan_tables</literal>
- roles are intended to allow administrators to easily configure a role for the
- purpose of monitoring the database server. They grant a set of common privileges
- allowing the role to read various useful configuration settings, statistics and
- other system information normally restricted to superusers.
- </para>
-
- <para>
- The <literal>pg_database_owner</literal> role has one implicit,
- situation-dependent member, namely the owner of the current database. Like
- any role, it can own objects or receive grants of access privileges.
- Consequently, once <literal>pg_database_owner</literal> has rights within a
- template database, each owner of a database instantiated from that template
- will exercise those rights. <literal>pg_database_owner</literal> cannot be
- a member of any role, and it cannot have non-implicit members. Initially,
- this role owns the <literal>public</literal> schema, so each database owner
- governs local use of the schema.
- </para>
-
- <para>
- The <literal>pg_signal_backend</literal> role is intended to allow
- administrators to enable trusted, but non-superuser, roles to send signals
- to other backends. Currently this role enables sending of signals for
- canceling a query on another backend or terminating its session. A user
- granted this role cannot however send signals to a backend owned by a
- superuser. See <xref linkend="functions-admin-signal"/>.
- </para>
-
- <para>
- The <literal>pg_read_server_files</literal>, <literal>pg_write_server_files</literal> and
- <literal>pg_execute_server_program</literal> roles are intended to allow administrators to have
- trusted, but non-superuser, roles which are able to access files and run programs on the
- database server as the user the database runs as. As these roles are able to access any file on
- the server file system, they bypass all database-level permission checks when accessing files
- directly and they could be used to gain superuser-level access, therefore
- great care should be taken when granting these roles to users.
- </para>
-
- <para>
- Care should be taken when granting these roles to ensure they are only used where
- needed and with the understanding that these roles grant access to privileged
- information.
- </para>
-
- <para>
- Administrators can grant access to these roles to users using the
- <link linkend="sql-grant"><command>GRANT</command></link> command, for example:
-
-<programlisting>
-GRANT pg_signal_backend TO admin_user;
-</programlisting>
+ objects.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-monitor" xreflabel="pg_monitor">
+ <term><varname>pg_monitor</varname></term>
+ <term><varname>pg_read_all_settings</varname></term>
+ <term><varname>pg_read_all_stats</varname></term>
+ <term><varname>pg_stat_scan_tables</varname></term>
+ <listitem>
+ <para>
+ These roles are intended to allow administrators to easily configure a
+ role for the purpose of monitoring the database server. They grant a
+ set of common privileges allowing the role to read various useful
+ configuration settings, statistics, and other system information
+ normally restricted to superusers.
+ </para>
+ <para>
+ <literal>pg_monitor</literal> allows reading/executing various
+ monitoring views and functions. This role is a member of
+ <literal>pg_read_all_settings</literal>,
+ <literal>pg_read_all_stats</literal> and
+ <literal>pg_stat_scan_tables</literal>.
+ </para>
+ <para>
+ <literal>pg_read_all_settings</literal> allows reading all configuration
+ variables, even those normally visible only to superusers.
+ </para>
+ <para>
+ <literal>pg_read_all_stats</literal> allows reading all pg_stat_* views
+ and use various statistics related extensions, even those normally
+ visible only to superusers.
+ </para>
+ <para>
+ <literal>pg_stat_scan_tables</literal> allows executing monitoring
+ functions that may take <literal>ACCESS SHARE</literal> locks on tables,
+ potentially for a long time (e.g., <function>pgrowlocks(text)</function>
+ in the <xref linkend="pgrowlocks"/> extension).
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-read-all-data" xreflabel="pg_read_all_data">
+ <term><varname>pg_read_all_data</varname></term>
+ <term><varname>pg_write_all_data</varname></term>
+ <listitem>
+ <para>
+ <literal>pg_read_all_data</literal> allows reading all data (tables,
+ views, sequences), as if having <command>SELECT</command> rights on
+ those objects and <literal>USAGE</literal> rights on all schemas. This
+ role does not bypass row-level security (RLS) policies. If RLS is being
+ used, an administrator may wish to set <literal>BYPASSRLS</literal> on
+ roles which this role is granted to.
+ </para>
+ <para>
+ <literal>pg_write_all_data</literal> allows writing all data (tables,
+ views, sequences), as if having <command>INSERT</command>,
+ <command>UPDATE</command>, and <command>DELETE</command> rights on those
+ objects and <literal>USAGE</literal> rights on all schemas. This role
+ does not bypass row-level security (RLS) policies. If RLS is being
+ used, an administrator may wish to set <literal>BYPASSRLS</literal> on
+ roles which this role is granted to.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-read-server-files" xreflabel="pg_read_server_files">
+ <term><varname>pg_read_server_files</varname></term>
+ <term><varname>pg_write_server_files</varname></term>
+ <term><varname>pg_execute_server_program</varname></term>
+ <listitem>
+ <para>
+ These roles are intended to allow administrators to have trusted, but
+ non-superuser, roles which are able to access files and run programs on
+ the database server as the user the database runs as. They bypass all
+ database-level permission checks when accessing files directly and they
+ could be used to gain superuser-level access. Therefore, great care
+ should be taken when granting these roles to users.
+ </para>
+ <para>
+ <literal>pg_read_server_files</literal> allows reading files from any
+ location the database can access on the server using
+ <command>COPY</command> and other file-access functions.
+ </para>
+ <para>
+ <literal>pg_write_server_files</literal> allows writing to files in any
+ location the database can access on the server using
+ <command>COPY</command> and other file-access functions.
+ </para>
+ <para>
+ <literal>pg_execute_server_program</literal> allows executing programs
+ on the database server as the user the database runs as using
+ <command>COPY</command> and other functions which allow executing a
+ server-side program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-signal-backend" xreflabel="pg_signal_backend">
+ <term><varname>pg_signal_backend</varname></term>
+ <listitem>
+ <para>
+ Allows signaling another backend to cancel a query or terminate its
+ session. Note that this role does not permit signaling backends owned
+ by a superuser. See <xref linkend="functions-admin-signal"/>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-use-reserved-connections" xreflabel="pg_use_reserved_connections">
+ <term><varname>pg_use_reserved_connections</varname></term>
+ <listitem>
+ <para>
+ Allows use of connection slots reserved via
+ <xref linkend="guc-reserved-connections"/>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</para>
-
</sect1>
<sect1 id="perm-functions">
--
2.39.3 (Apple Git-146)
Attachments:
[text/plain] v2-0001-revamp-predefined-roles-documentation.patch (19.2K, ../../ZnWe3RgnCV4RR9KB@nathan/2-v2-0001-revamp-predefined-roles-documentation.patch)
download | inline diff:
From 70ae4e75e59fb369bb46fccb579b9dedc6c24b11 Mon Sep 17 00:00:00 2001
From: Nathan Bossart <[email protected]>
Date: Tue, 18 Jun 2024 11:38:40 -0500
Subject: [PATCH v2 1/1] revamp predefined roles documentation
---
doc/src/sgml/config.sgml | 2 +-
doc/src/sgml/monitoring.sgml | 4 +-
doc/src/sgml/ref/checkpoint.sgml | 2 +-
doc/src/sgml/ref/reindex.sgml | 2 +-
doc/src/sgml/user-manag.sgml | 337 ++++++++++++++++---------------
5 files changed, 183 insertions(+), 164 deletions(-)
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index 0c7a9082c5..03e37209e6 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -731,7 +731,7 @@ include_dir 'conf.d'
<para>
Determines the number of connection <quote>slots</quote> that are
reserved for connections by roles with privileges of the
- <link linkend="predefined-roles-table"><literal>pg_use_reserved_connections</literal></link>
+ <xref linkend="predefined-role-pg-use-reserved-connections"/>
role. Whenever the number of free connection slots is greater than
<xref linkend="guc-superuser-reserved-connections"/> but less than or
equal to the sum of <varname>superuser_reserved_connections</varname>
diff --git a/doc/src/sgml/monitoring.sgml b/doc/src/sgml/monitoring.sgml
index b2ad9b446f..f30c1e53fa 100644
--- a/doc/src/sgml/monitoring.sgml
+++ b/doc/src/sgml/monitoring.sgml
@@ -286,8 +286,8 @@ postgres 27093 0.0 0.0 30096 2752 ? Ss 11:34 0:00 postgres: ser
other sessions, many columns will be null. Note, however, that the
existence of a session and its general properties such as its sessions user
and database are visible to all users. Superusers and roles with privileges of
- built-in role <literal>pg_read_all_stats</literal> (see also <xref
- linkend="predefined-roles"/>) can see all the information about all sessions.
+ built-in role <link linkend="predefined-role-pg-monitor"><literal>pg_read_all_stats</literal></link>
+ can see all the information about all sessions.
</para>
<table id="monitoring-stats-dynamic-views-table">
diff --git a/doc/src/sgml/ref/checkpoint.sgml b/doc/src/sgml/ref/checkpoint.sgml
index 28a1d717b8..db011a47d0 100644
--- a/doc/src/sgml/ref/checkpoint.sgml
+++ b/doc/src/sgml/ref/checkpoint.sgml
@@ -53,7 +53,7 @@ CHECKPOINT
<para>
Only superusers or users with the privileges of
- the <link linkend="predefined-roles-table"><literal>pg_checkpoint</literal></link>
+ the <xref linkend="predefined-role-pg-checkpoint"/>
role can call <command>CHECKPOINT</command>.
</para>
</refsect1>
diff --git a/doc/src/sgml/ref/reindex.sgml b/doc/src/sgml/ref/reindex.sgml
index 2942dccf1e..dcf70d14bc 100644
--- a/doc/src/sgml/ref/reindex.sgml
+++ b/doc/src/sgml/ref/reindex.sgml
@@ -305,7 +305,7 @@ REINDEX [ ( <replaceable class="parameter">option</replaceable> [, ...] ) ] { DA
partitioned table, such commands skip the privilege checks when processing
the individual partitions. Reindexing a schema or database requires being the
owner of that schema or database or having privileges of the
- <link linkend="predefined-roles-table"><literal>pg_maintain</literal></link>
+ <xref linkend="predefined-role-pg-maintain"/>
role. Note specifically that it's thus
possible for non-superusers to rebuild indexes of tables owned by
other users. However, as a special exception,
diff --git a/doc/src/sgml/user-manag.sgml b/doc/src/sgml/user-manag.sgml
index 07a16247d7..aa37823be2 100644
--- a/doc/src/sgml/user-manag.sgml
+++ b/doc/src/sgml/user-manag.sgml
@@ -590,101 +590,71 @@ DROP ROLE doomed_role;
and information. Administrators (including roles that have the
<literal>CREATEROLE</literal> privilege) can <command>GRANT</command> these
roles to users and/or other roles in their environment, providing those
- users with access to the specified capabilities and information.
+ users with access to the specified capabilities and information. For
+ example:
+
+<programlisting>
+GRANT pg_signal_backend TO admin_user;
+</programlisting>
</para>
+ <warning>
+ <para>
+ Care should be taken when granting these roles to ensure they are only used
+ where needed and with the understanding that these roles grant access to
+ privileged information.
+ </para>
+ </warning>
+
<para>
- The predefined roles are described in <xref linkend="predefined-roles-table"/>.
+ The predefined roles are described below.
Note that the specific permissions for each of the roles may change in
the future as additional capabilities are added. Administrators
should monitor the release notes for changes.
- </para>
- <table tocentry="1" id="predefined-roles-table">
- <title>Predefined Roles</title>
- <tgroup cols="2">
- <colspec colname="col1" colwidth="1*"/>
- <colspec colname="col2" colwidth="2*"/>
- <thead>
- <row>
- <entry>Role</entry>
- <entry>Allowed Access</entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry>pg_read_all_data</entry>
- <entry>Read all data (tables, views, sequences), as if having
- <command>SELECT</command> rights on those objects, and USAGE rights on
- all schemas, even without having it explicitly. This role does not have
- the role attribute <literal>BYPASSRLS</literal> set. If RLS is being
- used, an administrator may wish to set <literal>BYPASSRLS</literal> on
- roles which this role is GRANTed to.</entry>
- </row>
- <row>
- <entry>pg_write_all_data</entry>
- <entry>Write all data (tables, views, sequences), as if having
- <command>INSERT</command>, <command>UPDATE</command>, and
- <command>DELETE</command> rights on those objects, and USAGE rights on
- all schemas, even without having it explicitly. This role does not have
- the role attribute <literal>BYPASSRLS</literal> set. If RLS is being
- used, an administrator may wish to set <literal>BYPASSRLS</literal> on
- roles which this role is GRANTed to.</entry>
- </row>
- <row>
- <entry>pg_read_all_settings</entry>
- <entry>Read all configuration variables, even those normally visible only to
- superusers.</entry>
- </row>
- <row>
- <entry>pg_read_all_stats</entry>
- <entry>Read all pg_stat_* views and use various statistics related extensions,
- even those normally visible only to superusers.</entry>
- </row>
- <row>
- <entry>pg_stat_scan_tables</entry>
- <entry>Execute monitoring functions that may take <literal>ACCESS SHARE</literal> locks on tables,
- potentially for a long time.</entry>
- </row>
- <row>
- <entry>pg_monitor</entry>
- <entry>Read/execute various monitoring views and functions.
- This role is a member of <literal>pg_read_all_settings</literal>,
- <literal>pg_read_all_stats</literal> and
- <literal>pg_stat_scan_tables</literal>.</entry>
- </row>
- <row>
- <entry>pg_database_owner</entry>
- <entry>None. Membership consists, implicitly, of the current database owner.</entry>
- </row>
- <row>
- <entry>pg_signal_backend</entry>
- <entry>Signal another backend to cancel a query or terminate its session.</entry>
- </row>
- <row>
- <entry>pg_read_server_files</entry>
- <entry>Allow reading files from any location the database can access on the server with COPY and
- other file-access functions.</entry>
- </row>
- <row>
- <entry>pg_write_server_files</entry>
- <entry>Allow writing to files in any location the database can access on the server with COPY and
- other file-access functions.</entry>
- </row>
- <row>
- <entry>pg_execute_server_program</entry>
- <entry>Allow executing programs on the database server as the user the database runs as with
- COPY and other functions which allow executing a server-side program.</entry>
- </row>
- <row>
- <entry>pg_checkpoint</entry>
- <entry>Allow executing
- the <link linkend="sql-checkpoint"><command>CHECKPOINT</command></link>
- command.</entry>
- </row>
- <row>
- <entry>pg_maintain</entry>
- <entry>Allow executing
+ <variablelist>
+ <varlistentry id="predefined-role-pg-checkpoint" xreflabel="pg_checkpoint">
+ <term><varname>pg_checkpoint</varname></term>
+ <listitem>
+ <para>
+ Allows executing the
+ <link linkend="sql-checkpoint"><command>CHECKPOINT</command></link> command.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-create-subscription" xreflabel="pg_create_subscription">
+ <term><varname>pg_create_subscription</varname></term>
+ <listitem>
+ <para>
+ Allows users with <literal>CREATE</literal> permission on the database to issue
+ <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-database-owner" xreflabel="pg_database_owner">
+ <term><varname>pg_database_owner</varname></term>
+ <listitem>
+ <para>
+ Membership consists, implicitly, of the current database owner. Like
+ any role, it can own objects or receive grants of access privileges.
+ Consequently, once <literal>pg_database_owner</literal> has rights
+ within a template database, each owner of a database instantiated from
+ that template will exercise those rights.
+ <literal>pg_database_owner</literal> cannot be a member of any role, and
+ it cannot have non-implicit members. Initially, this role owns the
+ <literal>public</literal> schema, so each database owner governs local
+ use of the schema.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-maintain" xreflabel="pg_maintain">
+ <term><varname>pg_maintain</varname></term>
+ <listitem>
+ <para>
+ Allows executing
<link linkend="sql-vacuum"><command>VACUUM</command></link>,
<link linkend="sql-analyze"><command>ANALYZE</command></link>,
<link linkend="sql-cluster"><command>CLUSTER</command></link>,
@@ -692,78 +662,127 @@ DROP ROLE doomed_role;
<link linkend="sql-reindex"><command>REINDEX</command></link>,
and <link linkend="sql-lock"><command>LOCK TABLE</command></link> on all
relations, as if having <literal>MAINTAIN</literal> rights on those
- objects, even without having it explicitly.</entry>
- </row>
- <row>
- <entry>pg_use_reserved_connections</entry>
- <entry>Allow use of connection slots reserved via
- <xref linkend="guc-reserved-connections"/>.</entry>
- </row>
- <row>
- <entry>pg_create_subscription</entry>
- <entry>Allow users with <literal>CREATE</literal> permission on the
- database to issue
- <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link>.</entry>
- </row>
- </tbody>
- </tgroup>
- </table>
-
- <para>
- The <literal>pg_monitor</literal>, <literal>pg_read_all_settings</literal>,
- <literal>pg_read_all_stats</literal> and <literal>pg_stat_scan_tables</literal>
- roles are intended to allow administrators to easily configure a role for the
- purpose of monitoring the database server. They grant a set of common privileges
- allowing the role to read various useful configuration settings, statistics and
- other system information normally restricted to superusers.
- </para>
-
- <para>
- The <literal>pg_database_owner</literal> role has one implicit,
- situation-dependent member, namely the owner of the current database. Like
- any role, it can own objects or receive grants of access privileges.
- Consequently, once <literal>pg_database_owner</literal> has rights within a
- template database, each owner of a database instantiated from that template
- will exercise those rights. <literal>pg_database_owner</literal> cannot be
- a member of any role, and it cannot have non-implicit members. Initially,
- this role owns the <literal>public</literal> schema, so each database owner
- governs local use of the schema.
- </para>
-
- <para>
- The <literal>pg_signal_backend</literal> role is intended to allow
- administrators to enable trusted, but non-superuser, roles to send signals
- to other backends. Currently this role enables sending of signals for
- canceling a query on another backend or terminating its session. A user
- granted this role cannot however send signals to a backend owned by a
- superuser. See <xref linkend="functions-admin-signal"/>.
- </para>
-
- <para>
- The <literal>pg_read_server_files</literal>, <literal>pg_write_server_files</literal> and
- <literal>pg_execute_server_program</literal> roles are intended to allow administrators to have
- trusted, but non-superuser, roles which are able to access files and run programs on the
- database server as the user the database runs as. As these roles are able to access any file on
- the server file system, they bypass all database-level permission checks when accessing files
- directly and they could be used to gain superuser-level access, therefore
- great care should be taken when granting these roles to users.
- </para>
-
- <para>
- Care should be taken when granting these roles to ensure they are only used where
- needed and with the understanding that these roles grant access to privileged
- information.
- </para>
-
- <para>
- Administrators can grant access to these roles to users using the
- <link linkend="sql-grant"><command>GRANT</command></link> command, for example:
-
-<programlisting>
-GRANT pg_signal_backend TO admin_user;
-</programlisting>
+ objects.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-monitor" xreflabel="pg_monitor">
+ <term><varname>pg_monitor</varname></term>
+ <term><varname>pg_read_all_settings</varname></term>
+ <term><varname>pg_read_all_stats</varname></term>
+ <term><varname>pg_stat_scan_tables</varname></term>
+ <listitem>
+ <para>
+ These roles are intended to allow administrators to easily configure a
+ role for the purpose of monitoring the database server. They grant a
+ set of common privileges allowing the role to read various useful
+ configuration settings, statistics, and other system information
+ normally restricted to superusers.
+ </para>
+ <para>
+ <literal>pg_monitor</literal> allows reading/executing various
+ monitoring views and functions. This role is a member of
+ <literal>pg_read_all_settings</literal>,
+ <literal>pg_read_all_stats</literal> and
+ <literal>pg_stat_scan_tables</literal>.
+ </para>
+ <para>
+ <literal>pg_read_all_settings</literal> allows reading all configuration
+ variables, even those normally visible only to superusers.
+ </para>
+ <para>
+ <literal>pg_read_all_stats</literal> allows reading all pg_stat_* views
+ and use various statistics related extensions, even those normally
+ visible only to superusers.
+ </para>
+ <para>
+ <literal>pg_stat_scan_tables</literal> allows executing monitoring
+ functions that may take <literal>ACCESS SHARE</literal> locks on tables,
+ potentially for a long time (e.g., <function>pgrowlocks(text)</function>
+ in the <xref linkend="pgrowlocks"/> extension).
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-read-all-data" xreflabel="pg_read_all_data">
+ <term><varname>pg_read_all_data</varname></term>
+ <term><varname>pg_write_all_data</varname></term>
+ <listitem>
+ <para>
+ <literal>pg_read_all_data</literal> allows reading all data (tables,
+ views, sequences), as if having <command>SELECT</command> rights on
+ those objects and <literal>USAGE</literal> rights on all schemas. This
+ role does not bypass row-level security (RLS) policies. If RLS is being
+ used, an administrator may wish to set <literal>BYPASSRLS</literal> on
+ roles which this role is granted to.
+ </para>
+ <para>
+ <literal>pg_write_all_data</literal> allows writing all data (tables,
+ views, sequences), as if having <command>INSERT</command>,
+ <command>UPDATE</command>, and <command>DELETE</command> rights on those
+ objects and <literal>USAGE</literal> rights on all schemas. This role
+ does not bypass row-level security (RLS) policies. If RLS is being
+ used, an administrator may wish to set <literal>BYPASSRLS</literal> on
+ roles which this role is granted to.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-read-server-files" xreflabel="pg_read_server_files">
+ <term><varname>pg_read_server_files</varname></term>
+ <term><varname>pg_write_server_files</varname></term>
+ <term><varname>pg_execute_server_program</varname></term>
+ <listitem>
+ <para>
+ These roles are intended to allow administrators to have trusted, but
+ non-superuser, roles which are able to access files and run programs on
+ the database server as the user the database runs as. They bypass all
+ database-level permission checks when accessing files directly and they
+ could be used to gain superuser-level access. Therefore, great care
+ should be taken when granting these roles to users.
+ </para>
+ <para>
+ <literal>pg_read_server_files</literal> allows reading files from any
+ location the database can access on the server using
+ <command>COPY</command> and other file-access functions.
+ </para>
+ <para>
+ <literal>pg_write_server_files</literal> allows writing to files in any
+ location the database can access on the server using
+ <command>COPY</command> and other file-access functions.
+ </para>
+ <para>
+ <literal>pg_execute_server_program</literal> allows executing programs
+ on the database server as the user the database runs as using
+ <command>COPY</command> and other functions which allow executing a
+ server-side program.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-signal-backend" xreflabel="pg_signal_backend">
+ <term><varname>pg_signal_backend</varname></term>
+ <listitem>
+ <para>
+ Allows signaling another backend to cancel a query or terminate its
+ session. Note that this role does not permit signaling backends owned
+ by a superuser. See <xref linkend="functions-admin-signal"/>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry id="predefined-role-pg-use-reserved-connections" xreflabel="pg_use_reserved_connections">
+ <term><varname>pg_use_reserved_connections</varname></term>
+ <listitem>
+ <para>
+ Allows use of connection slots reserved via
+ <xref linkend="guc-reserved-connections"/>.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
</para>
-
</sect1>
<sect1 id="perm-functions">
--
2.39.3 (Apple Git-146)
^ permalink raw reply [nested|flat] 9+ messages in thread
* Re: improve predefined roles documentation
2024-06-13 19:48 improve predefined roles documentation Nathan Bossart <[email protected]>
2024-06-17 18:10 ` Re: improve predefined roles documentation Robert Haas <[email protected]>
2024-06-18 16:52 ` Re: improve predefined roles documentation Nathan Bossart <[email protected]>
2024-06-21 02:57 ` Re: improve predefined roles documentation David G. Johnston <[email protected]>
2024-06-21 15:40 ` Re: improve predefined roles documentation Nathan Bossart <[email protected]>
@ 2024-06-24 18:44 ` Robert Haas <[email protected]>
0 siblings, 0 replies; 9+ messages in thread
From: Robert Haas @ 2024-06-24 18:44 UTC (permalink / raw)
To: Nathan Bossart <[email protected]>; +Cc: David G. Johnston <[email protected]>; pgsql-hackers
On Fri, Jun 21, 2024 at 11:40 AM Nathan Bossart
<[email protected]> wrote:
> Done.
If you look at how the varlistentries begin, there are three separate patterns:
* Some document a single role and start with "Allow doing blah blah blah".
* Some document a couple of rolls so there are several paragraphs,
each beginning with "<literal>name_of_role</literal allows doing blah
blah blah". This is sometimes preceded by an introductory paragraph
explaining why this group of roles exists and what it's intended to
do.
* pg_database_owner is completely different from the rest, focusing on
explaining who is in the role rather than what the role gets to do.
I think the first two cases could be made more like each other by
changing the varlistentires that are just about one setting to use the
second format instead of the first, e.g. pg_checkpoint allows
executing the CHECKPOINT command.
I don't know what to do about pg_database_owner. I almost wonder if
that should be moved out of the table and documented as a special
case. Or maybe some more wordsmithing would add clarity. Or maybe it's
fine as-is.
--
Robert Haas
EDB: http://www.enterprisedb.com
^ permalink raw reply [nested|flat] 9+ messages in thread
end of thread, other threads:[~2024-06-24 18:44 UTC | newest]
Thread overview: 9+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2020-09-17 15:26 [PATCH 2/9] Move IS [NOT] NULL handling from BRIN support functions Tomas Vondra <[email protected]>
2024-06-13 19:48 improve predefined roles documentation Nathan Bossart <[email protected]>
2024-06-13 20:05 ` Re: improve predefined roles documentation David G. Johnston <[email protected]>
2024-06-13 20:11 ` Re: improve predefined roles documentation Nathan Bossart <[email protected]>
2024-06-17 18:10 ` Re: improve predefined roles documentation Robert Haas <[email protected]>
2024-06-18 16:52 ` Re: improve predefined roles documentation Nathan Bossart <[email protected]>
2024-06-21 02:57 ` Re: improve predefined roles documentation David G. Johnston <[email protected]>
2024-06-21 15:40 ` Re: improve predefined roles documentation Nathan Bossart <[email protected]>
2024-06-24 18:44 ` Re: improve predefined roles documentation Robert Haas <[email protected]>
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox