【问题标题】:TimescaleDB manual decompressionTimescaleDB手动解压
【发布时间】:2021-04-24 04:43:07
【问题描述】:

我在guide之后手动解压遇到了这个问题。

尝试以下步骤:

  1. 查找并暂停与压缩策略相关的作业。
SELECT alter_job(job_id => 
(
SELECT s.job_id
FROM timescaledb_information.jobs j
INNER JOIN timescaledb_information.job_stats s ON j.job_id = s.job_id
WHERE j.proc_name = 'policy_compression' AND s.hypertable_name = 'sensorsdata'
), scheduled => false, next_start => 'infinity');
  1. 按时间间隔解压缩块(全部没有当前块)。
SELECT decompress_chunk(chunk, if_compressed => true)
FROM show_chunks('sensorsdata', older_than => now()::timestamp) AS chunk;

或单名

SELECT decompress_chunk('_timescaledb_internal._hyper_1_2_chunk', if_compressed => true);

但是第2步导致数据库连接丢失。这发生在 pgadmin 和使用 EF Core 的 C# 应用程序中。

Picture 1. Connection loss during decompressing single chunk

但是当我连续多次执行此操作时,该命令会在某些尝试下执行。

这是我在日志文件中遇到的。

2021-04-20 21:22:50.188 GMT [7728] LOG:  statement: SELECT decompress_chunk('_timescaledb_internal._hyper_1_5_chunk', if_compressed => true);
2021-04-20 21:22:50.228 GMT [6972] LOG:  server process (PID 7728) was terminated by exception 0xC0000005
2021-04-20 21:22:50.228 GMT [6972] DETAIL:  Failed process was running: SELECT decompress_chunk('_timescaledb_internal._hyper_1_5_chunk', if_compressed => true);
2021-04-20 21:22:50.228 GMT [6972] HINT:  See C include file "ntstatus.h" for a description of the hexadecimal value.
2021-04-20 21:22:50.233 GMT [6972] LOG:  terminating any other active server processes
2021-04-20 21:22:50.248 GMT [16160] WARNING:  terminating connection because of crash of another server process
2021-04-20 21:22:50.248 GMT [16160] DETAIL:  The postmaster has commanded this server process to roll back the current transaction and exit, because another server process exited abnormally and possibly corrupted shared memory.
2021-04-20 21:22:50.248 GMT [16160] HINT:  In a moment you should be able to reconnect to the database and repeat your command.
2021-04-20 21:22:50.257 GMT [6972] LOG:  all server processes terminated; reinitializing
2021-04-20 21:22:50.337 GMT [1052] LOG:  database system was interrupted; last known up at 2021-04-20 21:22:49 GMT
2021-04-20 21:22:51.095 GMT [1052] LOG:  database system was not properly shut down; automatic recovery in progress
2021-04-20 21:22:51.102 GMT [1052] LOG:  invalid record length at 0/11801C78: wanted 24, got 0
2021-04-20 21:22:51.104 GMT [1052] LOG:  redo is not required
2021-04-20 21:22:51.159 GMT [6972] LOG:  database system is ready to accept connections
2021-04-20 21:22:51.217 GMT [16440] LOG:  TimescaleDB background worker launcher connected to shared catalogs
2021-04-20 21:22:51.819 GMT [7128] LOG:  statement: SET DateStyle=ISO; SET client_min_messages=notice; SELECT set_config('bytea_output','hex',false) FROM pg_settings WHERE name = 'bytea_output'; SET client_encoding='UNICODE';
2021-04-20 21:22:52.547 GMT [7128] LOG:  statement: SELECT version()
2021-04-20 21:22:52.549 GMT [7128] LOG:  statement: 
    SELECT
        db.oid as did, db.datname, db.datallowconn,
        pg_encoding_to_char(db.encoding) AS serverencoding,
        has_database_privilege(db.oid, 'CREATE') as cancreate, datlastsysoid,
        datistemplate
    FROM
        pg_database db
    WHERE db.datname = current_database()
2021-04-20 21:22:52.555 GMT [7128] LOG:  statement: 
            SELECT
                oid as id, rolname as name, rolsuper as is_superuser,
                CASE WHEN rolsuper THEN true ELSE rolcreaterole END as
                can_create_role,
                CASE WHEN rolsuper THEN true ELSE rolcreatedb END as can_create_db
            FROM
                pg_catalog.pg_roles
            WHERE
                rolname = current_user
2021-04-20 21:22:52.561 GMT [7128] LOG:  statement: SELECT decompress_chunk('_timescaledb_internal._hyper_1_5_chunk', if_compressed => true);
2021-04-20 21:22:52.688 GMT [7388] LOG:  statement: SET DateStyle=ISO; SET client_min_messages=notice; SELECT set_config('bytea_output','hex',false) FROM pg_settings WHERE name = 'bytea_output'; SET client_encoding='UNICODE';
2021-04-20 21:22:53.371 GMT [7388] LOG:  statement: SELECT version()
2021-04-20 21:22:53.373 GMT [7388] LOG:  statement: 
    SELECT
        db.oid as did, db.datname, db.datallowconn,
        pg_encoding_to_char(db.encoding) AS serverencoding,
        has_database_privilege(db.oid, 'CREATE') as cancreate, datlastsysoid,
        datistemplate
    FROM
        pg_database db
    WHERE db.datname = current_database()
2021-04-20 21:22:53.378 GMT [7388] LOG:  statement: 
            SELECT
                oid as id, rolname as name, rolsuper as is_superuser,
                CASE WHEN rolsuper THEN true ELSE rolcreaterole END as
                can_create_role,
                CASE WHEN rolsuper THEN true ELSE rolcreatedb END as can_create_db
            FROM
                pg_catalog.pg_roles
            WHERE
                rolname = current_user
2021-04-20 21:22:53.383 GMT [7388] LOG:  statement: SELECT oid, format_type(oid, NULL) AS typname FROM pg_type WHERE oid IN (2205) ORDER BY oid;

有什么想法吗?

【问题讨论】:

  • 这是 TimescaleDB 中代码错误的味道(分段违规)您应该向他们报告错误,最好使用可重现的测试用例。

标签: postgresql timescaledb


【解决方案1】:

您的config 显示什么:

select * from timescaledb_information.jobs where job_id=<compression job id>?

有时,如果后台作业的参数错误,它可能会失败并导致其他连接关闭。

【讨论】:

猜你喜欢
  • 2020-10-24
  • 2023-03-06
  • 2012-06-11
  • 1970-01-01
  • 2019-11-19
  • 2020-07-12
  • 2012-03-23
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多