Michael Paquier <michael@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