Control diagnostic artifacts in your deployment ​

Coordinator DB's documented configuration includes diagnostic log files and structured query history. It does not expose a hosted core-dump collection preference. Crash-artifact creation and collection are controlled by the operating system, container runtime or external monitoring service in your deployment.

Identify what is being collected ​

Ask the host administrator which crash handler receives artifacts, where they are stored and who can read them. Review that tool's own retention and upload settings. Changing query logging does not disable a host crash collector, and disabling a collector does not change ordinary SQL history.

Treat diagnostic artifacts as potentially sensitive: query text, credentials supplied by an application, or application data can appear in surrounding context. Do not attach a full memory artifact to a public issue merely to demonstrate a failed request.

Prefer a small reproduction ​

For a SQL failure, record the query identifier, exception code and a minimal redacted input. Structured system.query_log entries can provide duration and resource counters without a whole-process artifact. For server log paths and rotation, inspect the startup XML configuration.

Apply changes to external diagnostic tooling through the administrator who owns it, then verify its actual behavior on the host.

See configuration files, query history and logging settings.