Re: pg_dump / copy bugs with "big lines" ? - Mailing list pgsql-hackers

From Daniel Verite
Subject Re: pg_dump / copy bugs with "big lines" ?
Date
Msg-id 46b99b1f-92a6-40b2-b0b7-16c4a5253655@mm
Whole thread Raw
In response to Re: pg_dump / copy bugs with "big lines" ?  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
    Tomas Vondra wrote:

> 4) HandleParallelMessage needs a tweak, as it uses msg->len in a log
> message, but with '%d' and not '%ld' (as needed after changing the type
> to Size).

This could be %zu for the Size type. It's supported by elog().

However, it occurs to me that if we don't claim the 2GB..4GB range for
the CopyData message, because its Int32 length is not explicitly
unsigned as mentioned upthread, then it should follow that we don't
need to change StringInfo.{len,maxlen} from int type to Size type.

We should just set the upper limit for StringInfo.maxlen to
(0x7fffffff-1) instead of MaxAllocHugeSize for stringinfos with the
allow_long flag set, and leave the len and maxlen fields to their
original, int type.

Does that make sense?


Best regards,
--
Daniel Vérité
PostgreSQL-powered mailer: http://www.manitou-mail.org
Twitter: @DanielVerite



pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Password identifiers, protocol aging and SCRAM protocol
Next
From: Michael Paquier
Date:
Subject: Re: Password identifiers, protocol aging and SCRAM protocol