Conversation
Initialize debug_query_string to NULL at apply worker startup, since it is not a regular backend and has no client query string. Also clear debug_query_string in execute_sql_command_error_cb after the errcontext call, which already includes the SQL statement, to prevent it from appearing a second time in the LOG output.
When spock_read_insert returns NULL (relation not found), the exception log entry's local_tuple may still hold a pointer from a previous operation. Clear it before calling log_insert_exception to prevent get_tuple_origin from dereferencing freed memory.
📝 WalkthroughWalkthroughThe pull request refines error handling and logging cleanup in the replication apply process. When an INSERT fails due to a missing relation, the local tuple pointer is cleared. Debug query strings are explicitly nullified in error callbacks and apply worker initialization to prevent duplicate or uninitialized logging output. Changes
Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Should this include |
2 participants
Fix stale local_tuple pointer in the INSERT exception path when the
relation is not found, preventing get_tuple_origin from dereferencing
freed memory
Prevent debug_query_string from producing garbage in apply worker logs
by initializing it to NULL at startup and clearing it in the SQL error
context callback to avoid duplicate output