You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently when backup is restored via services with stdin usage, only isc_info_svc_line is recognized for sending backup data and isc_info_svc_to_eof is silently ignored (which cause endless loop in application that try to use it).
isc_info_svc_line is supposed to be used with text data and using it for binary data is not good from several points of view (EOLN marks, encodings, etc). Binary data is better to be transferred using isc_info_svc_to_eof.
Creating of new info item would be not good for backward compatibility.
The text was updated successfully, but these errors were encountered:
When backup is restored isc_info_svc_line is used only for monitoring data returned by "-v" switch of gbak which is definitely nothing other than text data. Stdin data passed to service is treated as binary stream.
It's clear that choice to use isc_info_svc_line to mark chunk of stdin sent to service via SPB was not wise choice (to say it mildly). Both isc_info_svc_to_eof and isc_info_svc_line are normally used for service output (query items) and they were created just for that purpose. Using them to identify items going in other direction only caused this confusion. It's pointless to ask that isc_info_svc_to_eof should be supported here as well (as an alias), and it would cause only more confusion as people would expect that they would mean two different things that would work similarly as in query direction (which they can't). In fact id used to send data to restore service has no special meaning except to identify the data chunk (so no EOLN at play here etc.). It could be ANY number devs would choose. Was using svc_line logically correct? No. Changing it to proper one (by logic to isc_info_svc_stdin) would be best, but that would break all existing code. At least isc_info_svc_line has some logic we could live with, but support for isc_info_svc_to_eof alias has no logic at all.
Submitted by: @aafemt
Currently when backup is restored via services with stdin usage, only isc_info_svc_line is recognized for sending backup data and isc_info_svc_to_eof is silently ignored (which cause endless loop in application that try to use it).
isc_info_svc_line is supposed to be used with text data and using it for binary data is not good from several points of view (EOLN marks, encodings, etc). Binary data is better to be transferred using isc_info_svc_to_eof.
Creating of new info item would be not good for backward compatibility.
The text was updated successfully, but these errors were encountered: