Re: Unhappy with error handling in psql's handleCopyOut()
От | Tom Lane |
---|---|
Тема | Re: Unhappy with error handling in psql's handleCopyOut() |
Дата | |
Msg-id | 30402.1392154142@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Unhappy with error handling in psql's handleCopyOut() (Stephen Frost <sfrost@snowman.net>) |
Ответы |
Re: Unhappy with error handling in psql's handleCopyOut()
Re: Unhappy with error handling in psql's handleCopyOut() |
Список | pgsql-hackers |
Stephen Frost <sfrost@snowman.net> writes: > I've not gotten back to it yet, but I ran into a related-seeming issue > where psql would happily chew up 2G of memory trying to send "COPY > failed" notices when it gets disconnected from a server that it's trying > to send data to mid-COPY. conn->sock was -1, connection was > 'CONNECTION_BAD', but the loop towards the end of handleCopyIn doesn't > care and nothing in libpq is changing PQresultStatus(): [ scratches head... ] Offhand I'd have expected PQgetResult to start returning error indications. It definitely will do that if it gets error indications from the I/O layer. Perhaps it didn't see any because asyncStatus had already been reset from PGASYNC_BUSY? If so, maybe we need an explicit test on the connection being good before we return valid PGRES_COPY_IN etc results. regards, tom lane
В списке pgsql-hackers по дате отправления: