Ошибки Postgres на Mac M1 на базе ARM с Big Sur

Question

С тех пор, как у меня появился новый MacBook Pro M1 на базе ARM, у меня постоянно возникали серьезные проблемы с PostgreSQL (psql 13.1). Независимо от того, использую ли я Rails-сервер или Foreman, я получаю ошибки как в моем браузере, так и в терминале, например PG::InternalError: ERROR: could not read block 15 in file "base/147456/148555": Bad address или же PG::Error (invalid encoding name: unicode) или же Error during failsafe response: PG::UnableToSend: no connection to the server. Странно то, что я могу часто обновлять браузер несколько раз, чтобы заставить что-то работать (до тех пор, пока они неизбежно не перестанут работать).

Я знаю обо всех проблемах конфигурации, связанных с компьютерами Mac M1 на базе ARM, поэтому я несколько раз удалял и переустанавливал все, от Homebrew до Postgres (с Rosetta, без Rosetta, используя arch -x86_64 brewкоманд, используя приложение Postgres вместо установки Homebrew). Я столкнулся с парой других людей на случайных досках сообщений, которые сталкиваются с той же проблемой (также на новых Mac) и им не повезло, поэтому я не хочу верить, что это проблема с повреждением диска. (Я также несколько раз запускал проверку Disk Utility FirstAid; он говорит, что все в порядке, но я понятия не имею, насколько это надежно.)

Я использую четность Thinkbot, чтобы синхронизировать мою базу данных среды разработки с тем, что сейчас находится в производстве. Когда я бегу development restore production, Я получаю в моем терминале сотни строк, которые выглядят так, как показано ниже (это сразу после завершения загрузки, но до того, как она перейдет к созданию значений по умолчанию, данных процесса, наборов последовательностей и т. Д.). Я считаю, что это корень проблемы, но я не уверен, каким будет решение:

      pg_restore: dropping TABLE [table name1]
pg_restore: from TOC entry 442; 1259 15829269 TABLE [table name1] u1oi0d2o8cha8f
pg_restore: error: could not execute query: ERROR:  table "[table name1]" does not exist
Command was: DROP TABLE "public"."[table name1]";
pg_restore: dropping TABLE [table name2]
pg_restore: from TOC entry 277; 1259 16955 TABLE [table name2] u1oi0d2o8cha8f
pg_restore: error: could not execute query: ERROR:  table "[table name2]" does not exist
Command was: DROP TABLE "public"."[table name2]";
pg_restore: dropping TABLE [table name3]
pg_restore: from TOC entry 463; 1259 15830702 TABLE [table name3] u1oi0d2o8cha8f
pg_restore: error: could not execute query: ERROR:  table "[table name3]" does not exist
Command was: DROP TABLE "public"."[table name3]";
pg_restore: dropping TABLE [table name4]
pg_restore: from TOC entry 445; 1259 15830421 TABLE [table name4] u1oi0d2o8cha8f
pg_restore: error: could not execute query: ERROR:  table "[table name4]" does not exist
Command was: DROP TABLE "public"."[table name4]";

Кто-нибудь еще испытал это? Мы будем очень благодарны за любые идеи решения. Спасибо!

РЕДАКТИРОВАТЬ: мне удалось воспроизвести ту же проблему на более старом MacBook Pro (также работающем с Big Sur), поэтому он кажется не связанным с M1, но потенциально связан с Big Sur.

Answer 1

Окончательное решение для этого:

Попробовав все обходные пути в другом ответе, я все еще иногда получал эту ошибку. Даже после сброса и восстановления базы данных, перехода на собственный postgres M1, выполнения всевозможных сценариев обслуживания и т. Д.

После долгой работы с postgresql.conf единственное, что надежно работало над этой проблемой на неопределенный срок (с тех пор не получили ошибку):

В postgresql.conf измените:

      max_worker_processes = 8

к

      max_worker_processes = 1

После внесения этого изменения я бросил все тесты в свою ранее подверженную ошибкам базу данных, и она ни разу не показала ту же ошибку. Раньше процедура извлечения, которую я выполнял в базе данных, содержащей около 20 миллионов записей, выдает ошибку неверного адреса после обработки 1-2 миллионов записей. Теперь он завершает весь процесс.

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

Answer 2

ОБНОВИТЬ:

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

Тем не менее, еще несколько поисков в списках рассылки postgres показали, что эта ошибка «неверный адрес» может возникать вместе с проблемами WAL (журнал упреждающей записи). Таким образом, я установил следующее в моем файле postgresql.conf, значительно увеличив размер буфера WAL:

wal_buffers = 4 МБ

и с тех пор не сталкивался с этой проблемой (снова постучите по дереву).

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

---

Время от времени возникала именно эта проблема на M1 MacBook Air: ERROR: could not read block и в различных перестановках.

Я читал на форуме postgres, что эта проблема может возникать при настройке виртуальных машин. Таким образом, я предполагаю, что это каким-то образом вызвано Розеттой. Даже если вы используете универсальную версию postgres, вы, вероятно, все еще используете двоичный файл x86 для некоторого дополнительного процесса (например, Python в моем случае).

Тем не менее, вот что решило проблему (пока): <strong>переиндексация базы данных.</strong>

Примечание: вам нужно переиндексировать из командной строки, не используя команды SQL. Когда я пытался переиндексировать с помощью SQL, я сталкивался с одной и той же ошибкой снова и снова, и переиндексация так и не завершилась.

Когда я переиндексировал с помощью командной строки, процесс завершился, и Bad Address ошибка не повторялась (стук по дереву).

Для меня это было просто:

      reindexdb name_of_database

Заняло 20-30 минут для БД 12 ГБ. Я не только больше не получаю эти ошибки, но и кажется, что база данных быстрее загружается. Только надеюсь, что проблема не вернется с повторным чтением / записью / созданием индекса в Rosetta. Я не уверен, почему это работает ... может быть, индексы, созданные на M1 Mac, подвержены повреждению? Может быть, индексы стали повреждены из-за записи или доступа из-за взаимодействия с Rosetta?

Answer 3

У меня были те же проблемы, что и у OP с момента установки PostgreSQL 13 с использованием MacPorts на моем Mac mini M1 (теперь на PostgreSQL 13.2).

я бы посмотрел could not read block ошибки:

1. Иногда при выполнении специальных запросов
2. Всегда при компиляции книги в R Markdown, которая делает несколько запросов
3. Всегда при работе с моей основной базой данных (в экземпляре на этой машине около 620 ГБ, и ошибка будет выдаваться очень быстро относительно того, как долго VACUUM FULL взял бы).

(Мое «исправление» до сих пор заключалось в том, чтобы направить мой Mac на сервер Ubuntu, который у меня запущен в углу моего офиса, поэтому для меня это не проблема.)

Но мне удалось сделать 2 и 3 без ошибок с момента обновления до Big Sur Beta 11.3 сегодня (оба отказали сразу перед обновлением). Возможно ли, что что-то в ОС устранило эту проблему?

Answer 4

я восстановил postgresql.confиз postgresql.conf.sample(и перезапустил сервер БД), и с тех пор он работает нормально.

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