I noticed that opossum's latest buildfarm run failed, evidently because it was set up with the user running the buildfarm named "pg_buildfarmer":
http://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=opossum&dt=2016-05-03%2018%3A43%3A31 That caused the bootstrap superuser's name to be "pg_buildfarmer". initdb didn't complain about this, but it was impossible to log in: 016-05-04 02:29:00.820 BST [5729505c.26:1] LOG: connection received: host=[local] 2016-05-04 02:29:00.927 BST [5729505c.26:2] LOG: connection authorized: user=pg_buildfarmer database=postgres 2016-05-04 02:29:00.932 BST [5729505c.26:3] FATAL: invalid value for parameter "session_authorization": "pg_buildfarmer" 2016-05-04 02:29:02.260 BST [5729505e.4396:1] LOG: connection received: host=[local] 2016-05-04 02:29:02.328 BST [5729505e.4396:2] LOG: connection authorized: user=pg_buildfarmer database=postgres 2016-05-04 02:29:02.333 BST [5729505e.4396:3] FATAL: invalid value for parameter "session_authorization": "pg_buildfarmer" 2016-05-04 02:29:03.662 BST [5729505f.57cd:1] LOG: connection received: host=[local] 2016-05-04 02:29:03.731 BST [5729505f.57cd:2] LOG: connection authorized: user=pg_buildfarmer database=postgres 2016-05-04 02:29:03.735 BST [5729505f.57cd:3] FATAL: invalid value for parameter "session_authorization": "pg_buildfarmer" I tried to duplicate this failure just now, and could not. Evidently, the failures opossum shows above come from the "cannot set role to pg_xxx" checks you had in check_session_authorization, which are gone as of commit a89505fd2. So in principle opossum should succeed if it were to try again today with the same environment. So this seems like another reason why removing those checks was an improvement, but I'm left with a policy question: should initdb disallow bootstrap superuser names like "pg_xxx"? This doesn't seem quite open-and-shut. On the one hand, if we leave it as-is, then people might be blindsided by future additions of built-in roles. On the other, if we forbid the case, it seems noticeably more likely that we'll break existing setups, because "pg_something" doesn't seem like a terribly unlikely choice for the name of the Postgres OS user. (Certainly opossum's owner would have to fix it, so that's one example out of a not very large sample space of buildfarm users...) Allowing a potential conflict for the bootstrap superuser is a much narrower conflict risk than any-old-user, so maybe it's okay to leave it as is. Also, the failure mode if you do get an actual, rather than hypothetical, conflict against a built-in role name isn't all that nice: $ initdb -U pg_signal_backend ... running bootstrap script ... FATAL: could not create unique index "pg_authid_rolname_index" DETAIL: Key (rolname)=(pg_signal_backend) is duplicated. ... While it's not hard to interpret this if you already know that "pg_signal_backend" is a reserved role name, an explicit failure message saying that the bootstrap superuser name can't begin with "pg_" would be more user-friendly. So that's a point in favor of having initdb reject the case. On the whole I lean to adding a restriction, but only weakly. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers