Re: pg_dump / copy bugs with "big lines" ?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: pg_dump / copy bugs with "big lines" ?
Дата
Msg-id CA+TgmobPaHSxPU523zdYHW3=H5pd9uFUsk3=d9YsHOsXdEKnuw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_dump / copy bugs with "big lines" ?  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Ответы Re: pg_dump / copy bugs with "big lines" ?  (Michael Paquier <michael.paquier@gmail.com>)
Re: pg_dump / copy bugs with "big lines" ?  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Mon, Apr 6, 2015 at 1:51 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> In any case, I don't think it would be terribly difficult to allow a bit
> more than 1GB in a StringInfo. Might need to tweak palloc too; ISTR there's
> some 1GB limits there too.

The point is, those limits are there on purpose.  Changing things
arbitrarily wouldn't be hard, but doing it in a principled way is
likely to require some thought.  For example, in the COPY OUT case,
presumably what's happening is that we palloc a chunk for each
individual datum, and then palloc a buffer for the whole row.  Now, we
could let the whole-row buffer be bigger, but maybe it would be better
not to copy all of the (possibly very large) values for the individual
columns over into a row buffer before sending it.  Some refactoring
that avoids the need for a potentially massive (1.6TB?) whole-row
buffer would be better than just deciding to allow it.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: Bringing text abbreviation debug output under the control of trace_sort
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: [PATCH] Add transforms feature