Am Montag, 22. Juni 2009 17:46:22 schrieben Sie:
> Lars Kanis <kanis@comcard.de> writes:
> > Am Montag, 22. Juni 2009 16:38:32 schrieben Sie:
> >> Tom Lane wrote:
> >>> IIUC this is a pre-existing bug/limitation in an extremely seldom-used
> >>> feature that we don't have any very good way to test. So I'm not
> >>> really excited about trying to fix it in RC at all. The chances of
> >>> breaking something seem much higher than the usefulness of the fix
> >>> would warrant.
> >>
> >> I think we'll see this feature used a lot more now, since we support
> >> client certificate authentication. I bet that's the reason why Lars is
> >> using it now, but wasn't using it before. Correct, Lars?
> >
> > That's right. Because clientside crypto engines and proper certificate
> > authentication is supported now, I would like to use a strong
> > smartcard-based login in our high security environment.
>
> OK, but I'm still worried about making a change of this sort (ie,
> modifying our interface to code that we don't control) so late in the
> release cycle. It seems like there is large potential for failure in
> contexts other than the one or two you are going to be able to test
> right now. Is there anything that can be done to reduce the risk?
The 3 different versions of the engine-code seems to me like this:
1. unpatched libpq
engines aren't initialized (so some don't work), engines aren't freed at th=
e=20
end of connection (memory leak), no changes to PGconn
2. the initial patch I posted
engines are initialized (so can work), engines aren't freed (memory leak), =
no=20
changes to PGconn only in engine code path
3. the current patch
engines are initialized, engines are freed, but problematic changes to PGco=
nn
Maybe version 2 (my initial patch) could be an alternative ?
regards
Lars Kanis