Skip to content

Проблема с комбинацией pg_pathman 1.4.7 + pg_repack 1.4.2 #134

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

Closed
ohmycto opened this issue Nov 17, 2017 · 5 comments
Closed

Comments

@ohmycto
Copy link

ohmycto commented Nov 17, 2017

Описание проблемы

Добрый день. В указанной конфигурации после применения pg_repack на секционированную таблицу данные "возвращаются" в родительскую таблицу. Ситуация выглядит очень странно, описываю путь воспроизведения ниже.

  1. Подготовка
CREATE TABLE my_table (
  key integer
  CONSTRAINT key PRIMARY KEY
);

INSERT INTO my_table (SELECT generate_series(1, 1000000));


SELECT create_hash_partitions('my_table', 'key', 10);
 create_hash_partitions
------------------------
                     10
(1 строка)
  1. Удостоверимся, что данные лежат только в партициях:
SELECT COUNT(*) FROM my_table;
  count
---------
 1000000
(1 строка)

SELECT COUNT(*) FROM ONLY my_table;
 count
-------
     0
(1 строка)
  1. Прогоняем pg_repack:
$ pg_repack -t my_schema.my_table
INFO: repacking table "my_schema.my_table"
  1. Смотрим count() еще раз:
SELECT COUNT(*) FROM my_table;
  count
---------
 1000000
(1 строка)

SELECT COUNT(*) FROM ONLY my_table;
  count
---------
 1000000
(1 строка)

Проблема в последнем COUNT(). Откуда в родительской таблице записи? Причем они есть и в партициях тоже:

SELECT COUNT(*) FROM ONLY my_table_0;
 count
--------
 100088
(1 строка)

SELECT COUNT(*) FROM ONLY my_table_1;
 count
-------
 99715
(1 строка)

SELECT COUNT(*) FROM ONLY my_table_3;
 count
-------
 99909
(1 строка)

Ну т.е. если бы они РЕАЛЬНО были бы в родительской таблице, то COUNT(*) без ONLY должен был бы показать в 2 раза больше строк, но он показывает ровно 1000000.

Вот EXPLAIN:

EXPLAIN ANALYZE SELECT COUNT(*) FROM ONLY my_table;
                                                       QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------
 Aggregate  (cost=16925.00..16925.01 rows=1 width=8) (actual time=110.382..110.382 rows=1 loops=1)
   ->  Seq Scan on my_table  (cost=0.00..14425.00 rows=1000000 width=0) (actual time=0.008..59.636 rows=1000000 loops=1)
 Planning time: 0.044 ms
 Execution time: 110.402 ms
(4 строки)

Пробовал делать то же самое в следующих вариациях:
а) таблица с ranged-секционированием по дате;
б) перед прогоном pg_repack добавлял SELECT set_enable_parent('my_table', FALSE);
в) pg_repack с опцией -I my_schema.my_table (чтобы он взял и все дочерние таблицы)

Результат тот же. Помогите, пожалуйста, разобраться. Может быть я что-то не учитываю? Спасибо!

Environment

SELECT * FROM pg_extension;
    extname    | extowner | extnamespace | extrelocatable | extversion |    extconfig    | extcondition
---------------+----------+--------------+----------------+------------+-----------------+--------------
 plpgsql       |       10 |           11 | f              | 1.0        |                 |
 btree_gin     |       10 |         2200 | t              | 1.0        |                 |
 fuzzystrmatch |       10 |       267783 | t              | 1.1        |                 |
 intarray      |       10 |         2200 | t              | 1.2        |                 |
 pgstattuple   |       10 |         2200 | t              | 1.4        |                 |
 postgres_fdw  |       10 |       267783 | t              | 1.0        |                 |
 btree_gist    |       10 |         2200 | t              | 1.2        |                 |
 pg_trgm       |       10 |         2200 | t              | 1.3        |                 |
 pg_pathman    |       10 |         2200 | f              | 1.4        | {333661,333672} | {"",""}
 hstore        |       10 |         2200 | t              | 1.4        |                 |
 pg_repack     |       10 |         2200 | f              | 1.4.2      |                 |
(11 строк)

SELECT version();
                                                 version
----------------------------------------------------------------------------------------------------------
 PostgreSQL 9.6.4 on x86_64-pc-linux-gnu, compiled by gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-18), 64-bit
(1 строка)

SELECT get_pathman_lib_version();
 get_pathman_lib_version
-------------------------
 10407
(1 строка)
@ohmycto ohmycto changed the title Проблема с комбинацией pg_pathman 1.4 + pg_repack 1.4.2 Проблема с комбинацией pg_pathman 1.4.7 + pg_repack 1.4.2 Nov 17, 2017
@funbringer
Copy link
Collaborator

Привет, @secoint

Спасибо за баг-репорт, будем разбираться.

funbringer added a commit to funbringer/pg_pathman that referenced this issue Dec 6, 2017
@funbringer
Copy link
Collaborator

Извиняюсь за задержку.

Проблема была найдена и исправлена, фикс уже в master. Скоро будет релиз с багфиксом.

@ohmycto
Copy link
Author

ohmycto commented Dec 6, 2017

Привет, спасибо!

Я правильно понимаю, что проблема на самом деле только в отображении? Никаких реальных записей в таблице, конечно же, нет?

@funbringer
Copy link
Collaborator

funbringer commented Dec 6, 2017

Я правильно понимаю, что проблема на самом деле только в отображении? Никаких реальных записей в таблице, конечно же, нет?

Нет, проблема именно в строках, они есть в родителе. Выкинуть их можно при помощи

truncate only parent_table;

Сама проблема вызвана неправильной обработкой запроса:

/* pg_pathman теряет ONLY */
insert into tbl1 select * from only tbl2;

Я подправил логику обработки ONLY, которая затрагивает все запросы.

@funbringer funbringer added the bug label Dec 6, 2017
funbringer added a commit to funbringer/pg_pathman that referenced this issue Dec 6, 2017
@funbringer
Copy link
Collaborator

Выпустил 1.4.9.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants