Re: [BUGS] BUG #14516: misleading error from libpq on out-of-memory
От | Tom Lane |
---|---|
Тема | Re: [BUGS] BUG #14516: misleading error from libpq on out-of-memory |
Дата | |
Msg-id | 32198.1485440032@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | [BUGS] BUG #14516: misleading error from libpq on out-of-memory (andrew@tao11.riddles.org.uk) |
Список | pgsql-bugs |
andrew@tao11.riddles.org.uk writes: > Running psql with a restricted memory ulimit to reproduce, one gets this > error message: > postgres=# \copy (select repeat('a',120000000)) to '/dev/null' > lost synchronization with server: got message type "d", length 120000001 Yeah. Per the code comments: /* * Before returning, enlarge the input buffer if needed to hold * the whole message. ... */ if (pqCheckInBufferSpace(conn->inCursor + (size_t) msgLength, conn)) { /* * XXX add some better recovery code... plan is to skip over * the message using its length, then report an error. For the * moment, just treat this like loss of sync (which indeed it * might be!) */ handleSyncLoss(conn, id, msgLength); } The point being that if we lost sync with the message stream, the symptom from this code's point of view would be a garbage header for the next message, which would include a possibly-bogus message type code and a definitely-insane-looking length. There's a sanity check involving VALID_LONG_MESSAGE_TYPE ahead of this, but with seven such message types, the odds of getting past that are not negligible. In short, it's not that easy to do better. Given the infrequency of complaints, I'm not sure it's worth spending time on. (The code in question has been like that since we started using message length words, in 2003; cf 5ed27e35f35f6c354b1a7120ec3a3ce57f93e73e. I don't think it's come up more than a couple of times since then.) regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
В списке pgsql-bugs по дате отправления: