| From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
|---|---|
| To: | Daniel Verite <daniel(at)manitou-mail(dot)org> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Craig Ringer <craig(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Ronan Dunklau <ronan(dot)dunklau(at)dalibo(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: pg_dump / copy bugs with "big lines" ? |
| Date: | 2017-01-10 14:46:00 |
| Message-ID: | 20170110144600.ck2c7kdli33e5hxo@alvherre.pgsql |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Alvaro Herrera wrote:
> Daniel Verite wrote:
>
> > My tests are OK too but I see an issue with the code in
> > enlargeStringInfo(), regarding integer overflow.
> > The bit of comment that says:
> >
> > Note we are assuming here that limit <= INT_MAX/2, else the above
> > loop could overflow.
> >
> > is obsolete, it's now INT_MAX instead of INT_MAX/2.
>
> I would keep this comment but use UINT_MAX/2 instead.
I rephrased the comment instead. As you say, the current code no longer
depends on that, but we will depend on something similar when we enlarge
the other variables.
With that, pushed and I hope this is closed for good.
If you or anyone else want to revisit things so that pg10 can load&dump
even larger tuples, be my guest. There are quite a few places that will
need to be touched, though (in particular, as I recall, the FE/BE
protocol.)
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | otheus uibk | 2017-01-10 15:10:53 | Re: RustgreSQL |
| Previous Message | Peter Eisentraut | 2017-01-10 14:06:28 | Re: Logical Replication WIP |