ничего подобного, обычный alter type .. add value для добавления значения в enum, самый обычный alter table ... set default для значения по-умолчанию как для всех прочих типов данных.
какие софтварные пределы, вы о чём? Простейшая полностью логичная идея оптимизации задачи: прочесть блок с одного диска и отправить на запись из памяти на несколько дисков параллельно вместо многократного чтения диска-источника.
а топологию подключения дисков можно обсуждать, когда вопрос будет про поиск источника замедления при одновременной записи нескольких десятков HDD. Я так понял, даже упомянутые выше 15 дисков не планируется подключить одновременно, куда там упираться?
покажите мне HDD, который способен упереться в полосу не то что SATA III, а хотя бы SATA II.
но да, общий процесс записи будет болтаться на уровне возможностей самого медленного из дисков. Но по времени это всё равно существенно быстрее, чем копировать каждый диск в отдельности. Время X записи самого медленного диска никуда не денется, как его не переставляй.
вы не можете просто так взять один hdd на 500гб и один hdd на 320гб и получить функционирующий raid1 на 500гб. raid1 на 320гб получить в этом случае можно. Но вот позволит ли вам ваша реализация рейда использовать каким-то образом оставшиеся 180гб на 500гб диске - вопрос к конкретной реализации.
Так в спецификации RAID есть примерно 6 типов массивов. И не каждый из них ведь будет так делать.
отчего же? Эталонные raid, без разницы 0, 1, 4, 5, 6 или 10 уровня, предполагают именно использование идентичного объёма дисков в массиве. Меняется логика чтения, записи и гарантий сохранения данных, но используемый объём тома массива одинаков для всех участников.
Вот JBOD по своему определению допускает разного объёма диски, но что по этому поводу думает конкретная реализация - тоже вопрос.
Кирилл Гусарев, повторюсь, ST3750640AS - это оочень давно было, примерно 2006 год по данным из гугла. А второй диск из какой эпохи, с чем сравниваете? Может между дисками по меньшей мере 10 лет развития.
Есть у меня ещё живой ровесник вашего, ST3320620AS. 75мб/с на последовательных операциях - его потолок с рождения. Какой SATA II, им до SATA I ещё двукратный запас по полосе интерфейса был в те стародавние времени.
а какая разница? 10 серия барракуды даже в идеальном seqscan в жизни не допрыгнет до предела SATA I. Хорошо если до 100мб/с последовательного чтения доберётся, что очень вряд ли. Ему же не меньше 15 лет уже.
вот так вот запросто локализуются многие проблемы и появляется конкретное направление для поиска ошибки. Это будет один из самых полезных навыков разработчика. Дальше искать конкретно как настраивается подключение к базе данных в проекте и где теряется имя базы. Очень возможна просто опечатка. DBNAME вместо DB_NAME или что-то вроде того. Примечательно, судя по логу, применение миграций и само приложение используют разные настройки соединения.
Я как раз и спрашиваю не ваше мнение, как называется ваша база, а мнение базы, в базе к каким именем был выполнен запрос. Потому что это запросто могут быть совершенно разные, сходу объясняющие суть ошибки.
В ubuntu логи базы обычно в /var/log/postgresql/postgresql-(major версия базы)-main.log можно поискать.
И чего нестандартного вы нашли в этом вопросе? Покажите с лога базы полный текст ошибки, запроса и имя базы в которой этот запрос выполнялся.
И обратите внимание на п.3.8. правил.
Неа, там тоже серьёзной математики нет.