> The point is I'm having a hard time seeing what the actual > gain is in not changing it back. If the principal name > mismatches, we're going to get rejected anyway, so it's not > really a problem there. Even though the gain in changing it > back isn't all that big either, why should we introduce > abackwards-incompatibility if there is no real gain in a > different part of the code.
Here's a patch that fixes the big problem and reverts the behaviour of appl_version to be compatible with 8.0. It's easy enough to isolate the changes that are around the appl_version - one line in backend/libpq/auth.c call to krb5_recvauth and one in interfaces/libpq/fe-auth.c call to krb5_sendauth. The call in backend/libpq/auth.c to krb5_sname_to_principal in 8.1beta2 was completely broken for a scenario where you *didn't* use virtual hosts, by setting pg_krb5_server to NULL... The call is needed there as well. //Magnus
krb5fix.patch
Description: krb5fix.patch
---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
