-
Notifications
You must be signed in to change notification settings - Fork 48
SPOC-551: add spock.log_verbosity and spock.apply_change_logging GUCs #477
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,30 @@ | ||
| /*------------------------------------------------------------------------- | ||
| * | ||
| * spock_change_log.h | ||
| * Public surface for spock.apply_change_logging output. | ||
| * | ||
| *------------------------------------------------------------------------- | ||
| */ | ||
| #ifndef SPOCK_CHANGE_LOG_H | ||
| #define SPOCK_CHANGE_LOG_H | ||
|
|
||
| /* | ||
| * Forward declarations only. spock_change_log.h is included from | ||
| * spock_apply.c right next to other spock_*.h headers, and pulling in | ||
| * spock_proto_native.h / spock_relcache.h would also drag in | ||
| * spock_compat.h via spock_output_plugin.h - the resulting macro | ||
| * redefinitions then collide with commands/trigger.h declarations | ||
| * pulled in further down the include chain (spock_common.h). | ||
| */ | ||
| struct SpockRelation; | ||
| struct SpockTupleData; | ||
|
|
||
| extern void spock_log_apply_change(const char *action, | ||
| struct SpockRelation *rel, | ||
| struct SpockTupleData *oldtup, | ||
| struct SpockTupleData *newtup, | ||
| const char *origin_name); | ||
|
|
||
| extern void spock_log_apply_ddl(const char *sql, const char *origin_name); | ||
|
|
||
| #endif /* SPOCK_CHANGE_LOG_H */ |
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -67,6 +67,7 @@ | |
| #include "replication/walsender_private.h" | ||
|
|
||
| #include "spock_autoddl.h" | ||
| #include "spock_change_log.h" | ||
| #include "spock_common.h" | ||
| #include "spock_conflict.h" | ||
| #include "spock_executor.h" | ||
|
|
@@ -1410,6 +1411,10 @@ handle_insert(StringInfo s) | |
| spock_apply_heap_insert(rel, &newtup); | ||
| } | ||
|
|
||
| if (!failed) | ||
| spock_log_apply_change("INSERT", rel, NULL, &newtup, | ||
| remote_origin_name); | ||
|
Comment on lines
+1414
to
+1416
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Prevent false “applied change” logs for skipped DML in exception replay modes. In Proposed fix- if (!failed)
+ if (!failed &&
+ !(MyApplyWorker->use_try_block &&
+ (exception_behaviour == TRANSDISCARD ||
+ exception_behaviour == SUB_DISABLE)))
spock_log_apply_change("INSERT", rel, NULL, &newtup,
remote_origin_name);- if (!failed)
+ if (!failed &&
+ !(MyApplyWorker->use_try_block &&
+ (exception_behaviour == TRANSDISCARD ||
+ exception_behaviour == SUB_DISABLE)))
spock_log_apply_change("UPDATE", rel,
hasoldtup ? &oldtup : NULL, &newtup,
remote_origin_name);- if (!failed)
+ if (!failed &&
+ !(MyApplyWorker->use_try_block &&
+ (exception_behaviour == TRANSDISCARD ||
+ exception_behaviour == SUB_DISABLE)))
spock_log_apply_change("DELETE", rel, &oldtup, NULL,
remote_origin_name);Also applies to: 1584-1587, 1716-1718 🤖 Prompt for AI Agents |
||
|
|
||
| /* | ||
| * DML operation is finished. Be paranoid and check memory context before | ||
| * switching out and cleaning the per-operation memory context | ||
|
|
@@ -1576,6 +1581,11 @@ handle_update(StringInfo s) | |
| spock_apply_heap_update(rel, hasoldtup ? &oldtup : &newtup, &newtup); | ||
| } | ||
|
|
||
| if (!failed) | ||
| spock_log_apply_change("UPDATE", rel, | ||
| hasoldtup ? &oldtup : NULL, &newtup, | ||
|
Comment on lines
+1584
to
+1586
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Should the change-log record really be gated by !failed? When user turns this on they almost certainly want to see the conflict and exception cases — those are the interesting ones. As written, it silently drops exactly the records you'd enable it to capture. I'd either always emit (with "incoming"|"applied"|"conflict"|"skipped" field, can be a generic string) or hook into spock_report_conflict()/log_insert_exception. Same comment applies to the DDL path in handle_sql — it logs before execution, so a failed DDL still produces an "action":"DDL" line that looks applied. |
||
| remote_origin_name); | ||
|
|
||
| spock_relation_close(rel, NoLock); | ||
|
|
||
| end_replication_step(); | ||
|
|
@@ -1703,6 +1713,10 @@ handle_delete(StringInfo s) | |
| spock_apply_heap_delete(rel, &oldtup); | ||
| } | ||
|
|
||
| if (!failed) | ||
| spock_log_apply_change("DELETE", rel, &oldtup, NULL, | ||
| remote_origin_name); | ||
|
|
||
| spock_relation_close(rel, NoLock); | ||
|
|
||
| end_replication_step(); | ||
|
|
@@ -2337,6 +2351,14 @@ handle_sql(QueuedMessage *queued_message, bool tx_just_started, char **sql) | |
| "item type %d expected %d", | ||
| MySubscription->name, r, WJB_DONE); | ||
|
|
||
| /* | ||
| * Emit the DDL change-log record (in both 'key_only' and 'verbose' | ||
| * modes) BEFORE execution. Logging at this point means the operator | ||
| * always sees what SQL was about to run, even if the execution itself | ||
| * later errors out. | ||
| */ | ||
| spock_log_apply_ddl(*sql, remote_origin_name); | ||
|
|
||
| /* Run the extracted SQL. */ | ||
| spock_execute_sql_command(*sql, queued_message->role, tx_just_started); | ||
| } | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we need both
spock.log_verbosityandspock.apply_change_logging. A single spock.debug_log_level using the stock server_message_level_options enum should be sufficient: increasing the DEBUG level increases verbosity exactly like Postgres itself.That also removes the need for the new SPOCK_DEBUG1/SPOCK_DEBUG2 macros — every existing ereport(DEBUG1/2, …) is already gated by log_min_messages, so the GUC simply controls the level at which spock's own debug output is emitted.