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

Поиск
Список
Период
Сортировка
От Alvaro Herrera
Тема Re: pg_dump / copy bugs with "big lines" ?
Дата
Msg-id 20160302154717.GA422573@alvherre.pgsql
обсуждение исходный текст
Ответ на Re: pg_dump / copy bugs with "big lines" ?  ("Daniel Verite" <daniel@manitou-mail.org>)
Ответы Re: pg_dump / copy bugs with "big lines" ?  (Michael Paquier <michael.paquier@gmail.com>)
Список pgsql-hackers
Daniel Verite wrote:

> The cause of the crash turns out to be, in enlargeStringInfo():
> 
> needed += str->len + 1;     /* total space required now */
> 
> needed is an int and str->len is an int64, so it overflows when the
> size has to grow beyond 2^31 bytes, fails to enlarge the buffer and
> overwrites memory after it.
> 
> When fixing it with a local int64 copy of the variable, the backend
> no longer crashes and COPY big2 TO 'file' appears to work.

Great, thanks for debugging.

> However, getting it to the client with \copy big2 to 'file'
> still produces the error in psql:
>    lost synchronization with server: got message type "d"
> and leaves an empty file, so there are more problems to solve to
> go beyond 2GB text per row.

Well, the CopyData message has an Int32 field for the message length.
I don't know the FE/BE protocol very well but I suppose each row
corresponds to one CopyData message, or perhaps each column corresponds
to one CopyData message.  In either case, it's not possible to go beyond
2GB without changing the protocol ...

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: pg_dump / copy bugs with "big lines" ?
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: WIP: Upper planner pathification