Re: Lift line-length limit for pg_service.conf

I wrote:
> Yeah. In a quick scan, it appears that there is only one caller that
> tries to save the result directly. So I considered making that caller
> do a pstrdup and eliminating the extra thrashing in t_readline itself.
> But it seemed too fragile; somebody would get it wrong and then have
> excess space consumption for their dictionary.

I had a better idea: if we get rid of t_readline() itself, which has
been deprecated for years anyway, we can have the calling layer
tsearch_readline_xxx maintain a StringInfo across the whole file
read process and thus get rid of alloc/free cycles for the StringInfo.

However ... while working on that, I realized that the usage of
the "curline" field in that code is completely unsafe. We save
a pointer to the result of tsearch_readline() for possible use
by the error context callback, *but the caller is likely to free that
string at some point*. So there is a window where an error would
result in trying to print already-freed data.

It looks like all of the core-code dictionaries free the result
string at the bottoms of their loops, so that the window for
trouble is pretty much empty. But contrib/dict_xsyn doesn't
do it like that, and so it's surely at risk. Any external
dictionaries that have copied that code would also be at risk.

So the attached adds a pstrdup/pfree to ensure that "curline"
has its own storage, putting us right back at two palloc/pfree
cycles per line. I don't think there's a lot of choice though;
in fact, I'm leaning to the idea that we need to back-patch
that part of this. The odds of trouble in a production build
probably aren't high, but still...

regards, tom lane