Re: [PATCH] Add error handling to byteaout.
От | Andreas Seltenreich |
---|---|
Тема | Re: [PATCH] Add error handling to byteaout. |
Дата | |
Msg-id | 87wpzkr340.fsf@ex.ansel.ydns.eu обсуждение исходный текст |
Ответ на | Re: [PATCH] Add error handling to byteaout. (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
Alvaro Herrera writes: > Why not just use an unsigned 64 bit variable? Also, perhaps > palloc_huge() avoids the whole problem in the first place ... Ja, that crossed my mind too, but the current limit is already far beyond anything that is usually configured for per-backend memory use, so I dismissed it. > though it might only move the issue around, if you cannot ship the > longer-than-1GB resulting escaped value. For example, when client and server encodings do not match: ,----[ mbutils.c ] | result = palloc(len * MAX_CONVERSION_GROWTH + 1); `---- This results in the fun fact that the maximum size for bytea values that are guaranteed to be pg_dumpable regardless of encoding/escaping settings is lower than 64MB. One thing that would also mitigate the problem is supporting a more efficient output format. For example, there's already means for base64-encoding in the backend: self=# select c, length(encode(mkbytea(28),c)) from (values ('hex'),('base64')) as v(c); c | length --------+-----------hex | 536870912base64 | 362623337 (2 rows) Maybe it is reasonable to make it available as another option for use in bytea_output? regards, Andreas
В списке pgsql-hackers по дате отправления: