Revert "Add documentation for timescaledb.bgw_log_level (#2744)" (#2769)

This reverts commit bfd3a79.
timescale · Oct 30, 2023 · d78a858 · d78a858
1 parent dd808cc
commit d78a858
Show file tree

Hide file tree

Showing 2 changed files with 16 additions and 71 deletions.
diff --git a/migrate/troubleshooting.md b/migrate/troubleshooting.md
@@ -86,7 +86,7 @@ WHERE id >= 1000;
 
 ## Restoring with concurrency
 
-If the directory format is used for `pg_dump` and `pg_restore`, concurrency can be
+If the directory format is used for pg_dump and pg_restore, concurrency can be
 employed to speed up the process. Unfortunately, loading the tables in the 
 `timescaledb_catalog` schema concurrently causes errors. Furthermore, the
 `tsdbadmin` user does not have sufficient privileges to turn off triggers in
@@ -125,9 +125,9 @@ policies, and continuous aggregate refresh policies. On Timescale, this table
 has a trigger which ensures that no database user can create or modify jobs
 owned by another database user. This trigger can provide an obstacle for migrations.
 
-If the `--no-owner` flag is used with `pg_dump` and `pg_restore`, all
-objects in the target database are owned by the user that ran
-`pg_restore`, likely `tsdbadmin`.
+If the `--no-owner` flag is used with pg_dump and pg_restore, all objects in
+the target database are owned by the user that ran pg_restore, likely
+`tsdbadmin`.
 
 If all the background jobs in the source database were owned by a user of the
 same name as the user running the restore (again likely `tsdbadmin`), then
@@ -138,13 +138,13 @@ are be automatically changed to be owned by the `tsdbadmin` user. In this case,
 one just needs to verify that the jobs do not make use of privileges that the
 `tsdbadmin` user does not possess.
 
-If background jobs are owned by one or more users other than the user
-employed in restoring, then there could be issues. To work around this
-issue, do not dump this table with `pg_dump`. Provide either
-`--exclude-table-data='_timescaledb_config.bgw_job'` or
-`--exclude-table='_timescaledb_config.bgw_job'` to `pg_dump` to skip
-this table.  Then, use `psql` and the `COPY` command to dump and
-restore this table with modified values for the `owner` column.
+If background jobs are owned by one or more users other than the user employed 
+in restoring, then there could be issues. To work around this issue, do not dump
+this table with `pg_dump`. Provide either
+`--exclude-table-data='_timescaledb_config.bgw_job'` or 
+`--exclude-table='_timescaledb_config.bgw_job'` to pg_dump to skip this table.
+Then, use psql and the COPY command to dump and restore this table with modified
+values for the `owner` column.
 
 ```bash
 # dump the _timescaledb_config.bgw_job table to a csv file replacing the owner 
@@ -204,10 +204,9 @@ particular details of the source schema and the migration approach chosen.
 
 ## Tablespaces
 
-Timescale does not support using custom tablespaces. Providing the
-`--no-tablespaces` flag to `pg_dump` and `pg_restore` when
-dumping/restoring the schema results in all objects being in the
-default tablespace as desired.
+Timescale does not support using custom tablespaces. Providing the 
+`--no-tablespaces` flag to pg_dump and pg_restore when dumping/restoring the
+schema results in all objects being in the default tablespace as desired.
 
 ## Only one database per instance
 
@@ -218,6 +217,6 @@ Timescale instance or "merge" source databases to target schemas.
 
 ## Superuser privileges
 
-The `tsdbadmin` database user is the most powerful available on Timescale, but it
+The tsdbadmin database user is the most powerful available on Timescale, but it
 is not a true superuser. Review your application for use of superuser privileged
-operations and mitigate before migrating.
+operations and mitigate before migrating.
diff --git a/use-timescale/troubleshoot-timescaledb.md b/use-timescale/troubleshoot-timescaledb.md
@@ -142,64 +142,10 @@ psql [your connect flags] -d your_timescale_db < dump_meta_data.sql > dumpfile.t
 
 and then inspect `dump_file.txt` before sending it together with a bug report or support question.
 
-## Debugging background jobs
-
-By default, background workers do not print a lot of information about
-execution. The reason for this is to avoid writing a lot of debug
-information to the PostgreSQL log unless necessary.
-
-To aid in debugging the background jobs, it is possible to increase
-the log level of the background workers without having to restart the
-server by setting the `timescaledb.bgw_log_level` GUC and reloading
-the configuration.
-
-```sql
-ALTER SYSTEM SET timescaledb.bgw_log_level TO 'DEBUG1';
-SELECT pg_reload_conf();
-```
-
-This variable is set to the value of
-[`log_min_messages`][log_min_messages] by default, which typically is
-`WARNING`. If the value of [`log_min_messages`][log_min_messages] is
-changed in the configuration file, it is used for
-`timescaledb.bgw_log_level` when starting the workers.
-
-### Debug level 1
-
-The amount of information printed at each level varies between jobs,
-but the information printed at `DEBUG1` is currently shown below.
-
-| Source            | Event                                                |
-|-------------------|------------------------------------------------------|
-| All jobs          | Job exit with runtime information                    |
-| All jobs          | Job scheduled for fast restart                       |
-| Custom job        | Execution started                                    |
-| Recompression job | Recompression job completed                          |
-| Reorder job       | Chunk reorder completed                              |
-| Reorder job       | Chunk reorder started                                |
-| Scheduler         | New jobs discovered and added to scheduled jobs list |
-| Scheduler         | Scheduling job for launch                            |
-
-### Debug level 2
-
-The amount of information printed at each level varies between jobs,
-but the information printed at `DEBUG2` is currently shown below.
-
-Note that all messages at level `DEBUG1` are also printed when you set
-the log level to `DEBUG2`, which is [normal PostgreSQL
-behaviour][log_min_messages].
-
-| Source    | Event                              |
-|-----------|------------------------------------|
-| All jobs  | Job found in jobs table            |
-| All jobs  | Job starting execution             |
-| Scheduler | Scheduled jobs list update started |
-
 [downloaded separately]: https://raw.githubusercontent.com/timescale/timescaledb/master/scripts/dump_meta_data.sql
 [github]: https://github.com/timescale/timescaledb/issues
 [slack]: https://slack.timescale.com/
 [track_io_timing]: https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-TRACK-IO-TIMING
 [update-db]: /self-hosted/:currentVersion:/upgrades/
 [using explain]: https://www.postgresql.org/docs/current/static/using-explain.html
 [worker-config]: /self-hosted/latest/configuration/about-configuration/#workers
-[log_min_messages]: https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-MIN-MESSAGES