-
-
Notifications
You must be signed in to change notification settings - Fork 81
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
NUL character handling #102
Labels
Comments
Thanks for pointing out. I'll try to look at this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The current approach to handle ASCII NUL chararacters is to use
insert_table_data()
instead ofcopy_data()
.I can live with that
insert_table_data
takes a very long time to complete, as long as there are no other consequences. But apparently, there is an FTWRL (flush table with read lock
), which causes the source database blocks all the write operations on the table, effectively makes the db unusable.I think a possible workaround is to offer an option to let the user choose whether to use
insert_table_data
. If the user choose to say no, an in-place pre-processing (just like zero timestamps) ingenerate_select_statements()
could be issued:
Regards.
The text was updated successfully, but these errors were encountered: