Daniel Gustafsson writes:
> On 23 Sep 2020, at 21:33, Tom Lane wrote:
>> 2. In the case where encoding conversion is performed, we still have
>> to pstrdup the result to have a safe copy for "curline". But I
>> realized that we're making a poor choice of which copy to return to
>> the caller. T
> On 23 Sep 2020, at 21:33, Tom Lane wrote:
>
> I wrote:
>> 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 w
I wrote:
> 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
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
>
Daniel Gustafsson writes:
>> On 22 Sep 2020, at 23:24, Tom Lane wrote:
>> In the same vein, here's a patch to remove the hard-coded line length
>> limit for tsearch dictionary files.
> LGTM. I like the comment on why not to return buf.data directly, that detail
> would be easy to miss.
Yeah.
> On 22 Sep 2020, at 23:24, Tom Lane wrote:
>
> In the same vein, here's a patch to remove the hard-coded line length
> limit for tsearch dictionary files.
LGTM. I like the comment on why not to return buf.data directly, that detail
would be easy to miss.
cheers ./daniel
In the same vein, here's a patch to remove the hard-coded line length
limit for tsearch dictionary files.
regards, tom lane
diff --git a/src/backend/tsearch/dict_thesaurus.c b/src/backend/tsearch/dict_thesaurus.c
index cb0835982d..64c979086d 100644
--- a/src/backend/tsearc
Daniel Gustafsson writes:
> [ 0001-Refactor-pg_service.conf-and-pg_restore-TOC-file-par.patch ]
I reviewed this and noticed that you'd missed adding resetStringInfo
calls in some code paths, which made me realize that while
pg_get_line_append() is great for its original customer in hba.c,
it kind
> On 21 Sep 2020, at 17:09, Tom Lane wrote:
>
> Daniel Gustafsson writes:
>> The pg_service.conf parsing thread [0] made me realize that we have a
>> hardwired
>> line length of max 256 bytes. Lifting this would be in line with recent work
>> for ecpg, pg_regress and pg_hba (784b1ba1a2 and 8f8
Daniel Gustafsson writes:
> The pg_service.conf parsing thread [0] made me realize that we have a
> hardwired
> line length of max 256 bytes. Lifting this would be in line with recent work
> for ecpg, pg_regress and pg_hba (784b1ba1a2 and 8f8154a50). The attached
> moves
> pg_service.conf to u
The pg_service.conf parsing thread [0] made me realize that we have a hardwired
line length of max 256 bytes. Lifting this would be in line with recent work
for ecpg, pg_regress and pg_hba (784b1ba1a2 and 8f8154a50). The attached moves
pg_service.conf to use the new pg_get_line_append API and a S
11 matches
Mail list logo
