pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
14+ messages / 6 participants
[nested] [flat]
Commits from this thread:
2021-04-13 69d5ca484b a7fcb62852 c7f0275fbd 041f4efd25 46b6635b77 c39aa1e878 Fix some inappropriately-disallowed uses of ALTER ROLE/DATABASE SET.
* BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
@ 2016-07-11 22:36 bossartn@amazon.com
2016-07-11 22:48 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Bossart, Nathan <bossartn@amazon.com>
2016-07-11 22:49 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 2 replies; 14+ messages in thread
From: bossartn@amazon.com @ 2016-07-11 22:36 UTC (permalink / raw)
To: pgsql-bugs
The following bug has been logged on the website:
Bug reference: 14242
Logged by: Nathan Bossart
Email address: bossartn@amazon.com
PostgreSQL version: 9.5.2
Operating system: 64-bit Linux
Description:
It is possible to modify the "role" setting in setconfig in the
pg_db_role_setting table such that it points to a nonexistent role. When
this is the case, restoring the output of pg_dumpall will fail due to the
missing role.
Steps to reproduce:
1. As superuser, execute "create role foo with login password 'test'"
2. As foo, execute "alter role foo set role = 'foo'"
3. As superuser, execute "alter role foo rename to bar"
a. At this point, the setconfig entry in pg_db_role_setting for
'bar' will contain '{role=foo}', which no longer exists
4. Execute pg_upgrade with the recommended steps in
https://www.postgresql.org/docs/current/static/pgupgrade.html
During pg_upgrade (more specifically, during the restore of the output from
pg_dumpall), the "ALTER ROLE "bar" SET "role" TO 'foo'" command generated
will fail with "ERROR: role "foo" does not exist".
This issue was identified by Jordan Lange and Nathan Bossart.
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
2016-07-11 22:36 BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail bossartn@amazon.com
@ 2016-07-11 22:48 ` Bossart, Nathan <bossartn@amazon.com>
1 sibling, 0 replies; 14+ messages in thread
From: Bossart, Nathan @ 2016-07-11 22:48 UTC (permalink / raw)
To: pgsql-bugs
A simple fix for this issue would be to temporarily create the role just for the ALTER ROLE SET command generated by pg_dumpall. I've attached a patch that does this.
Nathan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
Attachments:
restore_invalid_setconfig.patch (application/octet-stream, 10.9K) download
commit f9a087ad4a89e3ffad7c4bd196bcf89b7e496a72
Author: Nathan Bossart <bossartn@amazon.com>
Date: Mon Jul 11 18:47:16 2016 +0000
Create temporary role during pg_dumpall for roles with a setconfig
"role" setting to a nonexistent role.
It is possible to modify the "role" setting in setconfig in the
pg_db_role_setting table such that it points to a nonexistent role.
When this is the case, restoring the output of pg_dumpall will fail
due to the missing role:
ERROR: role "foo" does not exist
A notable place where this causes issues is during pg_upgrade. As
soon as pg_upgrade hits this error it fails.
This change prevents this error by creating the nonexistent role
temporarily for the generated ALTER ROLE SET statement that would
otherwise fail. This results in pg_dumpall output similar to the
following:
CREATE ROLE foo;
ALTER ROLE bar SET role TO 'foo';
DROP ROLE IF EXISTS foo;
This issue was identified by Jordan Lange and Nathan Bossart, and
this patch fixes bug #14242. Back-patch to all supported versions.
diff --git a/src/bin/pg_dump/pg_dumpall.c b/src/bin/pg_dump/pg_dumpall.c
index d4fb03e..15479b8 100644
--- a/src/bin/pg_dump/pg_dumpall.c
+++ b/src/bin/pg_dump/pg_dumpall.c
@@ -45,6 +45,7 @@ static void dumpCreateDB(PGconn *conn);
static void dumpDatabaseConfig(PGconn *conn, const char *dbname);
static void dumpUserConfig(PGconn *conn, const char *username);
static void dumpDbRoleConfig(PGconn *conn);
+static bool roleExists(const char *role_name, PGconn *conn);
static void makeAlterConfigCommand(PGconn *conn, const char *arrayitem,
const char *type, const char *name, const char *type2,
const char *name2);
@@ -1624,6 +1625,29 @@ dumpDbRoleConfig(PGconn *conn)
/*
+ * Helper function for makeAlterConfigCommand(...) to determine if a role exists.
+ */
+static bool
+roleExists(const char *role_name, PGconn *conn)
+{
+ PGresult *res;
+ bool role_exists;
+ PQExpBuffer query = createPQExpBuffer();
+
+ appendPQExpBuffer(query, "SELECT 1 FROM pg_roles WHERE rolname=");
+ appendStringLiteralConn(query, role_name, conn);
+ appendPQExpBuffer(query, ";");
+
+ res = executeQuery(conn, query->data);
+ destroyPQExpBuffer(query);
+
+ role_exists = PQntuples(res) > 0;
+ PQclear(res);
+ return role_exists;
+}
+
+
+/*
* Helper function for dumpXXXConfig().
*/
static void
@@ -1634,6 +1658,7 @@ makeAlterConfigCommand(PGconn *conn, const char *arrayitem,
char *pos;
char *mine;
PQExpBuffer buf;
+ bool temp_role_used = false;
mine = pg_strdup(arrayitem);
pos = strchr(mine, '=');
@@ -1646,6 +1671,21 @@ makeAlterConfigCommand(PGconn *conn, const char *arrayitem,
buf = createPQExpBuffer();
*pos = 0;
+
+ /*
+ * If a role's setconfig contains {role="foo"} and the role "foo"
+ * does not exist, the ALTER ROLE SET command generated here will
+ * fail. In order to prevent this error, the nonexistent role is
+ * temporarily created just for the invalid ALTER ROLE SET command.
+ */
+ if (pg_strcasecmp(type, "ROLE") == 0
+ && pg_strcasecmp(mine, "ROLE") == 0
+ && !roleExists(pos + 1, conn))
+ {
+ temp_role_used = true;
+ appendPQExpBuffer(buf, "CREATE ROLE %s;\n", fmtId(pos + 1));
+ }
+
appendPQExpBuffer(buf, "ALTER %s %s ", type, fmtId(name));
if (type2 != NULL && name2 != NULL)
appendPQExpBuffer(buf, "IN %s %s ", type2, fmtId(name2));
@@ -1661,6 +1701,14 @@ makeAlterConfigCommand(PGconn *conn, const char *arrayitem,
appendStringLiteralConn(buf, pos + 1, conn);
appendPQExpBufferStr(buf, ";\n");
+ /*
+ * If a temporary role was needed in order to prevent an invalid
+ * ALTER ROLE SET command from failing, it is deleted immediately
+ * after the ALTER ROLE SET command is executed.
+ */
+ if (temp_role_used)
+ appendPQExpBuffer(buf, "DROP ROLE IF EXISTS %s;\n", fmtId(pos + 1));
+
fprintf(OPF, "%s", buf->data);
destroyPQExpBuffer(buf);
free(mine);
diff --git a/src/bin/pg_dump/t/002_pg_dump.pl b/src/bin/pg_dump/t/002_pg_dump.pl
index fd4b9e8..5f4d0ba 100644
--- a/src/bin/pg_dump/t/002_pg_dump.pl
+++ b/src/bin/pg_dump/t/002_pg_dump.pl
@@ -277,6 +277,58 @@ my %tests = (
section_pre_data => 1,
section_post_data => 1,
test_schema_plus_blobs => 1, }, },
+ 'ALTER ROLE invalid_setconfig_test' => {
+ regexp => qr/^
+ \QALTER ROLE invalid_setconfig_test WITH \E
+ \QNOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN \E
+ \QNOREPLICATION NOBYPASSRLS;\E
+ /xm,
+ like => {
+ pg_dumpall_globals => 1,
+ pg_dumpall_globals_clean => 1, },
+ unlike => {
+ binary_upgrade => 1,
+ clean => 1,
+ clean_if_exists => 1,
+ createdb => 1,
+ defaults => 1,
+ exclude_dump_test_schema => 1,
+ exclude_test_table => 1,
+ exclude_test_table_data => 1,
+ no_privs => 1,
+ no_owner => 1,
+ only_dump_test_schema => 1,
+ only_dump_test_table => 1,
+ schema_only => 1,
+ section_pre_data => 1,
+ section_post_data => 1,
+ test_schema_plus_blobs => 1, }, },
+ 'ALTER ROLE valid_setconfig_test' => {
+ regexp => qr/^
+ \QALTER ROLE valid_setconfig_test WITH \E
+ \QNOSUPERUSER INHERIT NOCREATEROLE NOCREATEDB NOLOGIN \E
+ \QNOREPLICATION NOBYPASSRLS;\E
+ /xm,
+ like => {
+ pg_dumpall_globals => 1,
+ pg_dumpall_globals_clean => 1, },
+ unlike => {
+ binary_upgrade => 1,
+ clean => 1,
+ clean_if_exists => 1,
+ createdb => 1,
+ defaults => 1,
+ exclude_dump_test_schema => 1,
+ exclude_test_table => 1,
+ exclude_test_table_data => 1,
+ no_privs => 1,
+ no_owner => 1,
+ only_dump_test_schema => 1,
+ only_dump_test_table => 1,
+ schema_only => 1,
+ section_pre_data => 1,
+ section_post_data => 1,
+ test_schema_plus_blobs => 1, }, },
'ALTER FUNCTION dump_test.pltestlang_call_handler() OWNER TO' => {
regexp => qr/^
\QALTER FUNCTION dump_test.pltestlang_call_handler() \E
@@ -835,6 +887,110 @@ my %tests = (
section_pre_data => 1,
section_post_data => 1,
test_schema_plus_blobs => 1, }, },
+ 'CREATE ROLE invalid_setconfig_test' => {
+ create_order => 2,
+ create_sql => 'CREATE ROLE invalid_setconfig_test;',
+ regexp => qr/^CREATE ROLE invalid_setconfig_test;/m,
+ like => {
+ pg_dumpall_globals => 1,
+ pg_dumpall_globals_clean => 1, },
+ unlike => {
+ binary_upgrade => 1,
+ clean => 1,
+ clean_if_exists => 1,
+ createdb => 1,
+ defaults => 1,
+ exclude_dump_test_schema => 1,
+ exclude_test_table => 1,
+ exclude_test_table_data => 1,
+ no_privs => 1,
+ no_owner => 1,
+ only_dump_test_schema => 1,
+ only_dump_test_table => 1,
+ schema_only => 1,
+ section_pre_data => 1,
+ section_post_data => 1,
+ test_schema_plus_blobs => 1, }, },
+ 'CREATE ROLE valid_setconfig_test' => {
+ create_order => 3,
+ create_sql => 'CREATE ROLE valid_setconfig_test;',
+ regexp => qr/^CREATE ROLE valid_setconfig_test;/m,
+ like => {
+ pg_dumpall_globals => 1,
+ pg_dumpall_globals_clean => 1, },
+ unlike => {
+ binary_upgrade => 1,
+ clean => 1,
+ clean_if_exists => 1,
+ createdb => 1,
+ defaults => 1,
+ exclude_dump_test_schema => 1,
+ exclude_test_table => 1,
+ exclude_test_table_data => 1,
+ no_privs => 1,
+ no_owner => 1,
+ only_dump_test_schema => 1,
+ only_dump_test_table => 1,
+ schema_only => 1,
+ section_pre_data => 1,
+ section_post_data => 1,
+ test_schema_plus_blobs => 1, }, },
+ 'ALTER ROLE invalid_setconfig_test SET role=\'nonexistent_role\'' => {
+ create_sql => 'CREATE ROLE nonexistent_role;
+ ALTER ROLE invalid_setconfig_test SET role=\'nonexistent_role\';
+ DROP ROLE nonexistent_role;',
+ regexp => qr/^
+ \QCREATE ROLE nonexistent_role;\E
+ \n\QALTER ROLE invalid_setconfig_test SET role TO 'nonexistent_role';\E
+ \n\QDROP ROLE IF EXISTS nonexistent_role;\E
+ /xm,
+ like => {
+ pg_dumpall_globals => 1,
+ pg_dumpall_globals_clean => 1, },
+ unlike => {
+ binary_upgrade => 1,
+ clean => 1,
+ clean_if_exists => 1,
+ createdb => 1,
+ defaults => 1,
+ exclude_dump_test_schema => 1,
+ exclude_test_table => 1,
+ exclude_test_table_data => 1,
+ no_privs => 1,
+ no_owner => 1,
+ only_dump_test_schema => 1,
+ only_dump_test_table => 1,
+ schema_only => 1,
+ section_pre_data => 1,
+ section_post_data => 1,
+ test_schema_plus_blobs => 1, }, },
+ 'ALTER ROLE valid_setconfig_test SET role=\'valid_setconfig_test\'' => {
+ create_sql => 'ALTER ROLE valid_setconfig_test SET role=\'valid_setconfig_test\';',
+ regexp => qr/^
+ (?!\QCREATE ROLE valid_setconfig_test;\E\n)
+ \QALTER ROLE valid_setconfig_test SET role TO 'valid_setconfig_test';\E
+ (?!\n\QDROP ROLE IF EXISTS valid_setconfig_test;\E)
+ /xm,
+ like => {
+ pg_dumpall_globals => 1,
+ pg_dumpall_globals_clean => 1, },
+ unlike => {
+ binary_upgrade => 1,
+ clean => 1,
+ clean_if_exists => 1,
+ createdb => 1,
+ defaults => 1,
+ exclude_dump_test_schema => 1,
+ exclude_test_table => 1,
+ exclude_test_table_data => 1,
+ no_privs => 1,
+ no_owner => 1,
+ only_dump_test_schema => 1,
+ only_dump_test_table => 1,
+ schema_only => 1,
+ section_pre_data => 1,
+ section_post_data => 1,
+ test_schema_plus_blobs => 1, }, },
'CREATE DATABASE postgres' => {
regexp => qr/^
\QCREATE DATABASE postgres WITH TEMPLATE = template0 \E
@@ -2006,7 +2162,7 @@ my %tests = (
clean_if_exists => 1,
pg_dumpall_globals_clean => 1, }, },
'DROP ... commands' => { # catch-all for DROP
- regexp => qr/^DROP /m,
+ regexp => qr/^DROP (?!ROLE IF EXISTS nonexistent_role;)/m,
like => {}, # use more-specific options above
unlike => {
binary_upgrade => 1,
* Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
2016-07-11 22:36 BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail bossartn@amazon.com
@ 2016-07-11 22:49 ` Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:03 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
1 sibling, 1 reply; 14+ messages in thread
From: Tom Lane @ 2016-07-11 22:49 UTC (permalink / raw)
To: bossartn@amazon.com; +Cc: pgsql-bugs
bossartn@amazon.com writes:
> It is possible to modify the "role" setting in setconfig in the
> pg_db_role_setting table such that it points to a nonexistent role. When
> this is the case, restoring the output of pg_dumpall will fail due to the
> missing role.
> Steps to reproduce:
> 1. As superuser, execute "create role foo with login password 'test'"
> 2. As foo, execute "alter role foo set role = 'foo'"
> 3. As superuser, execute "alter role foo rename to bar"
> a. At this point, the setconfig entry in pg_db_role_setting for
> 'bar' will contain '{role=foo}', which no longer exists
> 4. Execute pg_upgrade with the recommended steps in
> https://www.postgresql.org/docs/current/static/pgupgrade.html
> During pg_upgrade (more specifically, during the restore of the output from
> pg_dumpall), the "ALTER ROLE "bar" SET "role" TO 'foo'" command generated
> will fail with "ERROR: role "foo" does not exist".
This does not seem like particularly a bug to me. Once you rename the
role, the ALTER ROLE SET setting is broken already, and it's on your head
to fix that, not pg_upgrade's. (Or in other words, promising that
pg_upgrade will succeed in already-malfunctioning installations seems
to me like a slope we'd better not start down.)
I am kind of wondering why we allow that parameter to be set in ALTER
ROLE/DATABASE SET at all, though; especially by unprivileged users.
Is this example based on a real use-case, and if so what is it?
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
2016-07-11 22:36 BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail bossartn@amazon.com
2016-07-11 22:49 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
@ 2016-07-11 23:03 ` David G. Johnston <david.g.johnston@gmail.com>
2016-07-11 23:12 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:18 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Andrew Gierth <andrew@tao11.riddles.org.uk>
0 siblings, 2 replies; 14+ messages in thread
From: David G. Johnston @ 2016-07-11 23:03 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: bossartn@amazon.com <bossartn@amazon.com>; pgsql-bugs
On Monday, July 11, 2016, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> bossartn@amazon.com <javascript:;> writes:
> > It is possible to modify the "role" setting in setconfig in the
> > pg_db_role_setting table such that it points to a nonexistent role. When
> > this is the case, restoring the output of pg_dumpall will fail due to the
> > missing role.
>
> > Steps to reproduce:
>
> > 1. As superuser, execute "create role foo with login password 'test'"
> > 2. As foo, execute "alter role foo set role = 'foo'"
> > 3. As superuser, execute "alter role foo rename to bar"
> > a. At this point, the setconfig entry in pg_db_role_setting for
> > 'bar' will contain '{role=foo}', which no longer exists
> > 4. Execute pg_upgrade with the recommended steps in
> > https://www.postgresql.org/docs/current/static/pgupgrade.html
>
> > During pg_upgrade (more specifically, during the restore of the output
> from
> > pg_dumpall), the "ALTER ROLE "bar" SET "role" TO 'foo'" command generated
> > will fail with "ERROR: role "foo" does not exist".
>
> This does not seem like particularly a bug to me. Once you rename the
> role, the ALTER ROLE SET setting is broken already, and it's on your head
> to fix that, not pg_upgrade's. (Or in other words, promising that
> pg_upgrade will succeed in already-malfunctioning installations seems
> to me like a slope we'd better not start down.)
>
>
I'm at a loss to understand what this does when it isn't broken. Assuming
valid grants does the user become the assigned role upon session startup?
Is the behavior even defined in the docs or is this, as suspected below,
and malfunctioning implementation detail?
I am kind of wondering why we allow that parameter to be set in ALTER
> ROLE/DATABASE SET at all, though; especially by unprivileged users.
> Is this example based on a real use-case, and if so what is it?
>
See also:
https://www.postgresql.org/message-id/20150212193420.2590.49423@wrigleys.postgresql.org
Upon further reflection we require custom variables to be namespaced.
There is not, to my knowledge, a documented guc variable named "role".
Something seems off here, but I cannot put my finger on it, even if the
error in question is one we cannot reasonably avoid.
David J.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
2016-07-11 22:36 BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail bossartn@amazon.com
2016-07-11 22:49 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:03 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
@ 2016-07-11 23:12 ` Tom Lane <tgl@sss.pgh.pa.us>
2016-07-12 00:01 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
1 sibling, 1 reply; 14+ messages in thread
From: Tom Lane @ 2016-07-11 23:12 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: bossartn@amazon.com <bossartn@amazon.com>; pgsql-bugs
"David G. Johnston" <david.g.johnston@gmail.com> writes:
>> bossartn@amazon.com <javascript:;> writes:
>>> 2. As foo, execute "alter role foo set role = 'foo'"
> I'm at a loss to understand what this does when it isn't broken. Assuming
> valid grants does the user become the assigned role upon session startup?
As written it does nothing much. But "SET ROLE" is defined by the SQL
standard, and what I'd expect this to do is execute an implicit SET ROLE
at login. Whether that's a good idea is pretty debatable, though, thus
my question whether we'd not be better off to forbid this.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
2016-07-11 22:36 BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail bossartn@amazon.com
2016-07-11 22:49 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:03 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
2016-07-11 23:12 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
@ 2016-07-12 00:01 ` David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 0 replies; 14+ messages in thread
From: David G. Johnston @ 2016-07-12 00:01 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: bossartn@amazon.com <bossartn@amazon.com>; pgsql-bugs
On Mon, Jul 11, 2016 at 7:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "David G. Johnston" <david.g.johnston@gmail.com> writes:
> >> bossartn@amazon.com <javascript:;> writes:
> >>> 2. As foo, execute "alter role foo set role = 'foo'"
>
> > I'm at a loss to understand what this does when it isn't broken.
> Assuming
> > valid grants does the user become the assigned role upon session startup?
>
> As written it does nothing much. But "SET ROLE" is defined by the SQL
> standard, and what I'd expect this to do is execute an implicit SET ROLE
> at login. Whether that's a good idea is pretty debatable, though, thus
> my question whether we'd not be better off to forbid this
> .
>
So, I just tested and we indeed do (9.6beta-2) make the effective role
the value associated with the "ROLE" configuration variable associated to
the user.
CREATE ROLE loginrole WITH LOGIN PASSWORD 'password';
CREATE ROLE grouprole;
GRANT grouprole TO loginrole
ALTER ROLE loginrole SET ROLE TO grouprole
psql -U loginrole postgres
SELECT current_role; --> grouprole
I'd say that the expression "SET ROLE" as defined does not match any of
the valid variations of ALTER ROLE that we've documented (i.e., ROLE is not
a "configuration_parameter"). We should document it explicitly.
ALTER ROLE { role_specification | ALL } [ IN DATABASE database_name ] SET
ROLE { TO | = } role_identifier
Does the standard provide guidance on the syntax for the equivalent of
"RESET ROLE"?
"The role_identifier in the <third> variant is used in conjunction with the
SET ROLE SQL command and causes a newly connected session to switch to the
named role. If for some reason the named role no longer exists - which can
happen if it is renamed or removed - future attempts to login will provoke
a WARNING and the original user will remain active. Note that this role
change happens after all configuration_parameters for the original role
have been setup - no configurations attached to the target role are applied.
role_identifier:
The name of an existing role
I would also take a page from the search_path GUC and ignore any attempt to
associate an undefined role - or at worse make it a warning. In fact, we
already do this during the login attempt. We should extend the forgiveness
to here as well.
DROP ROLE grouprole; -- OK
psql -U loginrole postgres
WARNING:\s\srole "grouprole" does not exist
SELECT current_role; --> loginrole
In hindsight we probably could do better if we didn't treat "ROLE" like any
other configuration parameter. I'm not sure what incremental improvements
could be made. Would a record in pg_depend that is set/cleared upon
invoking of ROLE-related commands? Would that be sufficient?
David J.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
2016-07-11 22:36 BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail bossartn@amazon.com
2016-07-11 22:49 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:03 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
@ 2016-07-11 23:18 ` Andrew Gierth <andrew@tao11.riddles.org.uk>
2016-07-11 23:22 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Bossart, Nathan <bossartn@amazon.com>
2016-07-11 23:22 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
1 sibling, 2 replies; 14+ messages in thread
From: Andrew Gierth @ 2016-07-11 23:18 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; bossartn\@amazon.com <bossartn@amazon.com>; pgsql-bugs
>>>>> "David" == David G Johnston <david.g.johnston@gmail.com> writes:
>> > 2. As foo, execute "alter role foo set role = 'foo'"
David> I'm at a loss to understand what this does when it isn't broken.
ALTER ROLE foo SET role = bar; will have the effect that when 'foo'
logs in, it will behave as if foo had immediately executed the command
SET ROLE bar;
I don't think this is documented but it has obvious uses.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
2016-07-11 22:36 BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail bossartn@amazon.com
2016-07-11 22:49 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:03 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
2016-07-11 23:18 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Andrew Gierth <andrew@tao11.riddles.org.uk>
@ 2016-07-11 23:22 ` Bossart, Nathan <bossartn@amazon.com>
1 sibling, 0 replies; 14+ messages in thread
From: Bossart, Nathan @ 2016-07-11 23:22 UTC (permalink / raw)
To: Andrew Gierth <andrew@tao11.riddles.org.uk>; David G. Johnston <david.g.johnston@gmail.com>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; pgsql-bugs
I cannot speak to any real use-cases beyond easily altering current_user every time you start a session.
Besides disallowing this parameter in ALTER ROLE SET statements entirely, perhaps pg_dumpall could simply skip it for missing roles? I cannot think of a use-case for maintaining an invalid setting here.
Nathan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
2016-07-11 22:36 BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail bossartn@amazon.com
2016-07-11 22:49 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:03 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
2016-07-11 23:18 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Andrew Gierth <andrew@tao11.riddles.org.uk>
@ 2016-07-11 23:22 ` Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:36 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Andrew Gierth <andrew@tao11.riddles.org.uk>
1 sibling, 1 reply; 14+ messages in thread
From: Tom Lane @ 2016-07-11 23:22 UTC (permalink / raw)
To: Andrew Gierth <andrew@tao11.riddles.org.uk>; +Cc: David G. Johnston <david.g.johnston@gmail.com>; bossartn\@amazon.com <bossartn@amazon.com>; pgsql-bugs
Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> I don't think this is documented but it has obvious uses.
Does it? If the named role is the same as the actual role, then it's
useless. If they're different, it seems at best confusing. In the
context of ALTER DATABASE SET, it seems both confusing and possibly
a security hazard.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
2016-07-11 22:36 BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail bossartn@amazon.com
2016-07-11 22:49 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:03 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
2016-07-11 23:18 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Andrew Gierth <andrew@tao11.riddles.org.uk>
2016-07-11 23:22 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
@ 2016-07-11 23:36 ` Andrew Gierth <andrew@tao11.riddles.org.uk>
2016-07-12 00:05 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 14+ messages in thread
From: Andrew Gierth @ 2016-07-11 23:36 UTC (permalink / raw)
To: Tom Lane <tgl@sss.pgh.pa.us>; +Cc: David G. Johnston <david.g.johnston@gmail.com>; bossartn\@amazon.com <bossartn@amazon.com>; pgsql-bugs
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
>> I don't think this is documented but it has obvious uses.
Tom> Does it?
For ALTER ROLE, there's actually a question that comes up not all that
infrequently on irc: "how do I arrange things so that what user 'foo'
does, by default, ends up owned by group role 'bar'"
I'm pretty sure I have never actually suggested that anyone do it this
way (because I had no idea it worked until I tried it just now), but I
can see the use case.
Tom> If the named role is the same as the actual role, then it's
Tom> useless. If they're different, it seems at best confusing. In
Tom> the context of ALTER DATABASE SET, it seems both confusing and
Tom> possibly a security hazard.
It _appears_ to silently fail if the user logging in is not actually a
member of the specified role. I have not looked at the code.
--
Andrew (irc:RhodiumToad)
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
2016-07-11 22:36 BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail bossartn@amazon.com
2016-07-11 22:49 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:03 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
2016-07-11 23:18 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Andrew Gierth <andrew@tao11.riddles.org.uk>
2016-07-11 23:22 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:36 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Andrew Gierth <andrew@tao11.riddles.org.uk>
@ 2016-07-12 00:05 ` David G. Johnston <david.g.johnston@gmail.com>
2016-07-12 02:08 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 14+ messages in thread
From: David G. Johnston @ 2016-07-12 00:05 UTC (permalink / raw)
To: Andrew Gierth <andrew@tao11.riddles.org.uk>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; bossartn@amazon.com <bossartn@amazon.com>; pgsql-bugs
On Mon, Jul 11, 2016 at 7:36 PM, Andrew Gierth <andrew@tao11.riddles.org.uk>
wrote:
> Tom> If the named role is the same as the actual role, then it's
> Tom> useless. If they're different, it seems at best confusing. In
> Tom> the context of ALTER DATABASE SET, it seems both confusing and
> Tom> possibly a security hazard.
>
> It _appears_ to silently fail if the user logging in is not actually a
> member of the specified role. I have not looked at the code.
>
WARNING:\s\spermission denied to set role "grouprole"
David J.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
2016-07-11 22:36 BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail bossartn@amazon.com
2016-07-11 22:49 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:03 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
2016-07-11 23:18 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Andrew Gierth <andrew@tao11.riddles.org.uk>
2016-07-11 23:22 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:36 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Andrew Gierth <andrew@tao11.riddles.org.uk>
2016-07-12 00:05 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
@ 2016-07-12 02:08 ` David G. Johnston <david.g.johnston@gmail.com>
2016-07-12 02:15 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
0 siblings, 1 reply; 14+ messages in thread
From: David G. Johnston @ 2016-07-12 02:08 UTC (permalink / raw)
To: Andrew Gierth <andrew@tao11.riddles.org.uk>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; bossartn@amazon.com <bossartn@amazon.com>; pgsql-bugs
On Mon, Jul 11, 2016 at 8:05 PM, David G. Johnston <
david.g.johnston@gmail.com> wrote:
> On Mon, Jul 11, 2016 at 7:36 PM, Andrew Gierth <
> andrew@tao11.riddles.org.uk> wrote:
>
>> Tom> If the named role is the same as the actual role, then it's
>> Tom> useless. If they're different, it seems at best confusing. In
>> Tom> the context of ALTER DATABASE SET, it seems both confusing and
>> Tom> possibly a security hazard.
>>
>> It _appears_ to silently fail if the user logging in is not actually a
>> member of the specified role. I have not looked at the code.
>>
>
> WARNING:\s\spermission denied to set role "grouprole"
>
>
Fun times...
[up-thread commands still in effect]
ALTER DATABASE postgres SET ROLE loginrole2;
psql -U loginrole postgres
WARNING: permission denied to set role "grouprole"
WARNING: permission denied to set role "loginrole2"
postgres=>
Note the code comment at about: src/backend/commands/user.c@478-479
"
Although it will work to say
ALTER ROLE role ROLE rolenames", we don't document it.
"
While that's good to know the specific syntax in the comment is invalid on
its face. It also doesn't say "why" we don't document it nor why it needs
to be accepted. I'd say at this point the why is immaterial though.
I'm still in favor of documenting both commands and reducing our parental
involvement here.
In light of the above double-warning I'm concerned that "precedence" isn't
happening correctly here - but that could be an implementation artifact
(the more specific combination is executed second so that it ends up
overriding any settings attempted to be set by the less specific
configuration). In this case, though, the failed attempt to set the
db+role setting would have resulted in the role setting taking effect if it
was valid. I don't recall us making this distinction clear in the
documentation.
Tangentially, I'm not sure what, if anything, to do with 18.1 given this
knowledge. 18.1 was written assuming that the GUC variation of these
commands cannot fail and thus it is safe to execute the DATABASE version
followed by a ROLE specific version followed by a DATABASE+ROLE version.
This seems correct on its face and as I said up-thread this whole ROLE
business isn't really a configuration variable even though it is
shoe-horned into that infrastructure. I'm inclined to leave well enough
alone.
David J.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
2016-07-11 22:36 BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail bossartn@amazon.com
2016-07-11 22:49 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:03 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
2016-07-11 23:18 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Andrew Gierth <andrew@tao11.riddles.org.uk>
2016-07-11 23:22 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:36 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Andrew Gierth <andrew@tao11.riddles.org.uk>
2016-07-12 00:05 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
2016-07-12 02:08 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
@ 2016-07-12 02:15 ` David G. Johnston <david.g.johnston@gmail.com>
2021-04-14 20:13 ` Re: [BUGS] BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Bruce Momjian <bruce@momjian.us>
0 siblings, 1 reply; 14+ messages in thread
From: David G. Johnston @ 2016-07-12 02:15 UTC (permalink / raw)
To: Andrew Gierth <andrew@tao11.riddles.org.uk>; +Cc: Tom Lane <tgl@sss.pgh.pa.us>; bossartn@amazon.com <bossartn@amazon.com>; pgsql-bugs
Sorry...I keep trying to dig deeper and keep discovering/realizing stuff.
On Mon, Jul 11, 2016 at 10:08 PM, David G. Johnston <
david.g.johnston@gmail.com> wrote:
>
>>
> Fun times...
> [up-thread commands still in effect]
> ALTER DATABASE postgres SET ROLE loginrole2;
> psql -U loginrole postgres
> WARNING: permission denied to set role "grouprole"
> WARNING: permission denied to set role "loginrole2"
> postgres=>
>
> In light of the above double-warning I'm concerned that "precedence" isn't
> happening correctly here - but that could be an implementation artifact
> (the more specific combination is executed second so that it ends up
> overriding any settings attempted to be set by the less specific
> configuration). In this case, though, the failed attempt to set the
> db+role setting would have resulted in the role setting taking effect if it
> was valid. I don't recall us making this distinction clear in the
> documentation.
>
>
Actually, apparently the system realizes its attempt to SET ROLE <role-set
value> failed and proceeded to attempt to "SET ROLE <db-set value>" -
assuming the visible order is reflective of reality. So it does have the
necessary smarts and also fall-back-try-again logic.
The rest of the documentation observations stand.
David J.
^ permalink raw reply [nested|flat] 14+ messages in thread
* Re: [BUGS] BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail
2016-07-11 22:36 BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail bossartn@amazon.com
2016-07-11 22:49 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:03 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
2016-07-11 23:18 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Andrew Gierth <andrew@tao11.riddles.org.uk>
2016-07-11 23:22 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:36 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail Andrew Gierth <andrew@tao11.riddles.org.uk>
2016-07-12 00:05 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
2016-07-12 02:08 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
2016-07-12 02:15 ` Re: BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail David G. Johnston <david.g.johnston@gmail.com>
@ 2021-04-14 20:13 ` Bruce Momjian <bruce@momjian.us>
0 siblings, 0 replies; 14+ messages in thread
From: Bruce Momjian @ 2021-04-14 20:13 UTC (permalink / raw)
To: David G. Johnston <david.g.johnston@gmail.com>; +Cc: Andrew Gierth <andrew@tao11.riddles.org.uk>; Tom Lane <tgl@sss.pgh.pa.us>; bossartn@amazon.com <bossartn@amazon.com>; pgsql-bugs
FYI, Tom just applied a patch to properly detect/fix this issue.
---------------------------------------------------------------------------
On Mon, Jul 11, 2016 at 10:15:38PM -0400, David G. Johnston wrote:
> Sorry...I keep trying to dig deeper and keep discovering/realizing stuff.
>
> On Mon, Jul 11, 2016 at 10:08 PM, David G. Johnston <david.g.johnston@gmail.com
> > wrote:
>
>
>
> Fun times...
> [up-thread commands still in effect]
> ALTER DATABASE postgres SET ROLE loginrole2;
> psql -U loginrole postgres
> WARNING: permission denied to set role "grouprole"
> WARNING: permission denied to set role "loginrole2"
> postgres=>
>
> In light of the above double-warning I'm concerned that "precedence" isn't
> happening correctly here - but that could be an implementation artifact
> (the more specific combination is executed second so that it ends up
> overriding any settings attempted to be set by the less specific
> configuration). In this case, though, the failed attempt to set the
> db+role setting would have resulted in the role setting taking effect if it
> was valid. I don't recall us making this distinction clear in the
> documentation.
>
>
>
> Actually, apparently the system realizes its attempt to SET ROLE <role-set
> value> failed and proceeded to attempt to "SET ROLE <db-set value>" - assuming
> the visible order is reflective of reality. So it does have the necessary
> smarts and also fall-back-try-again logic.
>
> The rest of the documentation observations stand.
>
> David J.
>
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
^ permalink raw reply [nested|flat] 14+ messages in thread
end of thread, other threads:[~2021-04-14 20:13 UTC | newest]
Thread overview: 14+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2016-07-11 22:36 BUG #14242: Role with a setconfig "role" setting to a nonexistent role causes pg_upgrade to fail bossartn@amazon.com
2016-07-11 22:48 ` Bossart, Nathan <bossartn@amazon.com>
2016-07-11 22:49 ` Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:03 ` David G. Johnston <david.g.johnston@gmail.com>
2016-07-11 23:12 ` Tom Lane <tgl@sss.pgh.pa.us>
2016-07-12 00:01 ` David G. Johnston <david.g.johnston@gmail.com>
2016-07-11 23:18 ` Andrew Gierth <andrew@tao11.riddles.org.uk>
2016-07-11 23:22 ` Bossart, Nathan <bossartn@amazon.com>
2016-07-11 23:22 ` Tom Lane <tgl@sss.pgh.pa.us>
2016-07-11 23:36 ` Andrew Gierth <andrew@tao11.riddles.org.uk>
2016-07-12 00:05 ` David G. Johnston <david.g.johnston@gmail.com>
2016-07-12 02:08 ` David G. Johnston <david.g.johnston@gmail.com>
2016-07-12 02:15 ` David G. Johnston <david.g.johnston@gmail.com>
2021-04-14 20:13 ` Bruce Momjian <bruce@momjian.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox