Michael Paquier <mich...@paquier.xyz> writes: > On Sat, Jun 29, 2019 at 04:36:51PM -0400, Tom Lane wrote: >> I think this is likely a consequence of ca129e58c0 having modified >> 010_dump_connstr.pl to use "regress_postgres" not "postgres" as the >> bootstrap superuser name in the source cluster. I suppose I overlooked >> some dependency on the user name that only affects SSPI ... but what?
> Didn't you get trapped with something similar to what has been fixed > in d9f543e? If you want pg_hba.conf to be correctly set up for SSPI > on Windows, you should pass "auth_extra => ['--create-role', > 'regress_postgres']" to the init() method initializing the node. After further study, I think the root issue here is that pg_regress.c's config_sspi_auth() has no provision for non-default bootstrap superuser names --- it makes a mapping entry for (what should be) the default superuser name whether the cluster is using that or not. I now see that 010_dump_connstr.pl is hacking around that by doing my $envar_node = get_new_node('destination_envar'); $envar_node->init(extra => [ '-U', $dst_bootstrap_super, '--locale=C', '--encoding=LATIN1' ]); $envar_node->run_log( [ $ENV{PG_REGRESS}, '--config-auth', $envar_node->data_dir, '--create-role', "$dst_bootstrap_super,$restore_super" ]); that is, it's explicitly listing the non-default bootstrap superuser among the roles to be "created". This is all pretty weird and undocumented ... We could apply the same hack on the source node, but I wonder if it wouldn't be better to make this less of a kluge. I'm tempted to propose that "pg_regress --config-auth --user XXX" should understand XXX as the bootstrap superuser name, and then we could clean up 010_dump_connstr.pl by using that. regards, tom lane