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" ?
Re: pg_dump / copy bugs with "big lines" ? |
Список | 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 по дате отправления: