It was pointed out to me off-list that pg_dump fails if a user-defined datatype's output routine is silly enough to emit NOTICE messages: the rest of the table data simply disappears without any warning.
What is happening is that libpq's pqGetCopyData3() drops out of COPY_OUT state upon seeing a NoticeResponse message. The rest of the data arrives OK but is silently discarded by libpq because it's no longer in COPY_OUT state. Our protocol specification is ambiguous about this case: in http://developer.postgresql.org/pgdocs/postgres/protocol-flow.html#PROTOCOL-COPY it is stated that : The frontend should treat receipt of ErrorResponse (or indeed any : message type other than CopyData or CopyDone) as terminating the : copy-out mode. which seems to legitimize libpq's behavior. But the very next section states that : ... frontends should always be prepared to accept and display : NoticeResponse messages, even when the connection is nominally idle. and : Good practice is to be able to accept NotificationResponse at any : point in the protocol. and there is similar verbiage about ParameterStatus. So there are basically two ways we could respond to this: decide that libpq is broken, and fix it; or decide that we should suppress non-CopyData messages during COPY OUT. I dislike the second alternative, because one of the motivations for dividing COPY data into messages in the V3 protocol was specifically to allow other stuff to be interpersed into the message stream. (We had to suppress Notice messages during COPY OUT in the old protocol, but that restriction was supposedly gotten rid of in V3; the backend thinks so anyway.) An unknown (at this point) is what other client-side code might need to be fixed if we decide it's a client-side bug. One argument in favor of fixing it on the client side is that we customarily advise people to use the newer pg_dump during a version upgrade; so a client-side fix would be more likely to be effective during an upgrade. An argument against fixing it on the client side is that it's at least conceivable that some apps would fail to cope with NoticeProcessor callbacks during COPY OUT. However that seems like it's just an application bug anyway. This seems like a fairly serious bug, since it could lead to dumps that are silently missing some data. The fact that we've not seen it reported before, though it's been this way since 7.4, suggests that the actual number of places that could emit NOTICEs during COPY OUT is pretty low --- but I have a bad feeling that it's not zero, even without considering debugging printouts in user-written data types. It seems at least theoretically possible for ParameterStatus reports to be emitted, too. Comments? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly