Вопросы Теги

Пост-ГРЭС pg_dump выводит базу данных в другом порядке каждый раз

Я пишу Сценарий PHP (который также использует команды удара Linux), который пробежит тестовые сценарии путем выполнения следующего:

Я использую базу данных PostgreSQL (8.4.2)...

1.) Создайте DB 2.) Изменяют DB 3.) Хранят дамп базы данных DB (pg_dump)

4.) Сделайте регрессионное тестирование путем выполнения шагов 1.) и 2.), и затем берут другой дамп базы данных и сравнивают его (разность) с исходным дампом базы данных от шага номер 3.)

Однако я нахожу, что pg_dump будет не всегда выводить базу данных таким же образом. Это выведет вещи в другом порядке каждый раз. Поэтому, когда я делаю разность на двух дампах базы данных, сравнение приведет к этим двум файлам, являющимся отличающимся, когда они будут на самом деле тем же, только в другом порядке.

Существует ли другой путь, которым я могу пойти о выполнении pg_dump?

Спасибо!

17
задан littleK 1 February 2010 в 18:04
поделиться

6 ответов

Невозможно заставить PG_Dump сбросить данные в каком-либо конкретном порядке, так как он сбрасывает данные в порядок диска - это намного быстрее.

Вы можете использовать параметры «-D -D» для PG_Dump, а затем «Сортировать» вывод, но в Newlines в данных сделает отсортированный вывод непригодным для использования. Но для базового сравнения, изменилось ли что-то, это хватило бы.

9
ответ дан 30 November 2019 в 11:22
поделиться

Если вы просто заинтересованы в схеме:

, вы могли бы сделать свой различие от таблицы, используя комбинацию этих параметров для сброса схемы только для одной таблицы за раз. Затем вы можете сравнить их индивидуально или кота их все в один файл в известном порядке. 

-s, --schema-only           dump only the schema, no data
-t, --table=TABLE           dump the named table(s) only

Чтобы генерировать список таблиц для подачи выше, запрос information_schema.tables .

2
ответ дан 30 November 2019 в 11:22
поделиться

Если вы делаете это для обучения, то определенно Scheme с SICP . Это будет тяжело и обидно и взорвет ваш разум, если у вас нет опыта с этим, но вы научитесь многому.

Если вы хотите использовать функциональное программирование на практике, то стоит посмотреть на F #, Scala и Clojure.

-121--2180553-

Обычно Эрланг примерно в 4-5 раз медленнее, чем делает то же самое в C, хотя то, что он теряет в скорости, повышает эффективность, простоту и стабильность. Делая вещи, которые Эрланг превосходит в, я думаю, что это лежит около 2-3 раз C. Это также может быть скомпилировано в собственные двоичные файлы, чтобы ускорить его примерно на 20% больше.

Просто знайте, что есть куча обычных вещей, в которых Эрланг не хорош, таких как манипулирование последовательностями и хруст чисел. Эрланг был сделан для распространения (в большинстве чувств слова), так что это то, в чем он потрясающе.

О, и о великолепной производительности на одной машине: не более половины того, что было бы у приложения C. Но опять же, это все-таки, вероятно, в 30-40 раз быстрее, чем эквивалент в рубине, фп или питоне.

-121--3181275-

Здесь следует различать схему и данные. Схема выгружается в довольно детерминированном порядке, большинство объектов в алфавитном порядке, ограничено межобъектными зависимостями. Есть некоторые ограниченные случаи, когда порядок не полностью ограничен и может показаться случайным для внешнего наблюдателя, но это может быть исправлено в следующей версии.

Данные, с другой стороны, выгружаются в дисковом порядке. Это обычно то, что вы хотите, потому что вы хотите, чтобы дампы были быстрыми и не использовать безумные количества ресурсов для сортировки. Можно заметить, что при «изменении БД» выполняется ОБНОВЛЕНИЕ, которое фактически удаляет старое значение и добавляет новое значение в конце. И это, конечно, расстроит вашу стратегию.

Инструментом, который может быть более подходящим для вашей цели, является pg _ компаратор .

11
ответ дан 30 November 2019 в 11:22
поделиться

Нередко PostgreSQL ведет себя недетерминированно - возможно, в фоновом режиме происходят реорганизационные процессы, спровоцированные таймером, или что-то подобное. Далее я не знаю, как заставить pg_dump воспроизводить бит-идентичный вывод на последующих запусках.

Я предлагаю изменить логику сравнения, потому что именно сравнение является неправильным - оно сообщает о различиях, в то время как оба дампа представляют одно и то же состояние базы данных. Это, конечно, означает некоторую дополнительную работу, но, на мой взгляд, это правильный способ атаки на проблему.

1
ответ дан 30 November 2019 в 11:22
поделиться

Вот удобный сценарий для предварительной обработки вывода pg_dump , чтобы сделать его более подходящим для сравнения и сохранения в системе контроля версий:

https://github.com/akaihola/pgtricks

pg_dump_splitsort.py разбивает дамп на следующие файлы:

  • 0000_prologue.sql : все до первой КОПИИ
  • 0001_ < схема>. <таблица> .sql
    .
    .
    NNNN_ . .sql : данные для каждой таблицы , отсортированные по первому полю
  • 9999_epilogue.sql : все после последней КОПИИ

    • Файлы для данные таблицы пронумерованы, поэтому для воссоздания базы данных можно использовать простое сортированное объединение всех файлов: 

    $ cat *.sql | psql <database>

    Я обнаружил, что хороший способ быстро взглянуть на различия между дампами - использовать комбинацию Инструмент для всего каталога: 

    $ meld old-dump/ new-dump/

    Сохранение дампа в системе контроля версий также дает хорошее представление о различиях. Вот как настроить git для использования цвета в различиях: 

    # ~/.gitconfig
[color]
        diff = true
[color "diff"]
        frag = white blue bold
        meta = white green bold
        commit = white red bold

    Примечание: Если вы создали / удалили / переименовали таблицы, не забудьте удалить все файлы .sql перед пост-обработкой нового дампа.

    14
    ответ дан 30 November 2019 в 11:22
    поделиться

    По состоянию на май 2010 г. существует патч к pg_dump , который может быть полезен всем, кто интересуется этим вопросом - он добавляет в эту утилиту параметр «--ordered»:

    Использование --ordered будет упорядочивать данные первичный ключ или уникальный индекс, если есть существует, и используйте "самый маленький" заказ (т.е. наименьшее количество столбцы, необходимые для уникального заказа).

    Обратите внимание, что --ordered может разрушить ваш сервер базы данных, если вы попытаетесь заказать очень большие таблицы, поэтому используйте их с умом.

    Я не тестировал, но думаю, попробовать стоит.

    3
    ответ дан 30 November 2019 в 11:22
    поделиться
    Другие вопросы по тегам:

    Похожие вопросы:

    © 2017 - 2020 Вопросы и ответы по программированию