* Tom Lane (tgl@sss.pgh.pa.us) wrote:
> Stephen Frost <sfrost@snowman.net> writes:
> > I've pushed a change which should clean it up by simply loading the
> > module after each reconnects is done, more-or-less simulating having it
> > be in shared_preload_libraries. It also wasn't using the correct
> > database for reconnecting.
>
> > I'll keep an eye on it.
>
> Another thing that looks not amazingly well-thought-out about that
> regression test is that it creates a superuser role with a known name
> (and no password, not that adding a password would make it better).
> This seems like it's just asking for trouble, especially in installcheck
> scenarios where failure partway through would leave the superuser lying
> around ready to be exploited. Do we *really* need that in the test?
I'm not sure that we need it.. It's certainly darn handy to have since
we're reconnecting to get the role attributes updated when the GUCs are
being changed and we need to be doing that as a superuser. We certainly
create superuser login roles throughout the regression tests today,
including those in core (CREATE ROLE foreign_data_user LOGIN SUPERUSER;
for example). I had thought the issues with having a superuser role in
the regression tests had been addressed by not allowing the socket to be
in a public spot and the other changes..
We don't currently drop the role though at the end though.
If we had the name of the role to reconnect as then I don't think we'd
need the "super" role, but we'd need to be able to reconnect as that
role too, to be able to flip back and forth between roles which are not
superusers and ones which are.
Will investigate that, suggestions certainly welcome. Looks like
there's a more interesting issue that termite ran into.
Thanks!
Stephen