Magnus Hagander wrote:
Applied.
//Magnus
Thanks.
And thanks, Tom, for pointing out my multiple attempts to free.
-selena
--
Selena Deckelmann
End Point Corporation
sel...@endpoint.com
503-282-2512
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to yo
Tom Lane wrote:
> Magnus Hagander writes:
>> Tom Lane wrote:
>>> It sure looks like that's going to try to free new_parsed_lines more
>>> than once. Shouldn't clean_hba_list be done just once?
>
>> Yeah, it should be done in the if branch down below. And I think by our
>> coding standards (or at
Magnus Hagander writes:
> Tom Lane wrote:
>> It sure looks like that's going to try to free new_parsed_lines more
>> than once. Shouldn't clean_hba_list be done just once?
> Yeah, it should be done in the if branch down below. And I think by our
> coding standards (or at least by our conventions
Tom Lane wrote:
> Selena Deckelmann writes:
>> Currently, load_hba() bails on the first parsing error. It would be
>> better for the typo-prone sysadmin if it reported ALL errors, and THEN
>> bailed out.
>
>> This patch implements that behavior. Tested against 8.4 HEAD this morning.
>
> It su
Selena Deckelmann writes:
> Currently, load_hba() bails on the first parsing error. It would be
> better for the typo-prone sysadmin if it reported ALL errors, and THEN
> bailed out.
> This patch implements that behavior. Tested against 8.4 HEAD this morning.
It sure looks like that's going t
Currently, load_hba() bails on the first parsing error. It would be
better for the typo-prone sysadmin if it reported ALL errors, and THEN
bailed out.
This patch implements that behavior. Tested against 8.4 HEAD this morning.
Idea is to do a similar thing for postgresql.conf. That is a little
