Я бы даже слово добавил: блокировки снимутся только после окончания транзакции.
Вернуть блокировку до окончания транзакции невозможно (кроме некоторых нетранзакционных блокировок).
При обрыве соединения будет сделан rollback - ведь commit не сказали, база не может знать завершена ли транзакция и потому единственный вариант - откатывать. Но про клиента ремарка хорошая, неизвестно, вдруг клиент как раз перед отключением вызывает неяный commit.
Во-первых - зачем? Это бесполезное справочное поле.
Во-вторых - никак. Не, по идее SPD это EEPROM и при большом желании можно перепрограммировать, но DDR3 2400мгц в JEDEC вообще никак не стандартизирован. Да и нестандартное напряжение в JEDEC части SPD не указать, только в XMP расширении.
Отличия нет. База к которой fdw подключается вообще ничего не знает о fdw, для неё это рядовой libpq клиент. Любой запрос к любой таблице хватает как минимум ACCESS SHARE на эту таблицу. И даже ACCESS SHARE конфликтует с ACCESS EXCLUSIVE, который требуют drop, vacuum full, reindex и многие виды alter table.
Смотреть, как уже сказал, в pg_stat_activity на предмет долгих транзакций. Ну или, если хотите, можете поискать в pg_locks, pid'ы удерживающих блокировки транзакций там тоже будут.
fdw никаких локов не держит от одного своего существования на другом сервере. Транзакции через него проходящие на этот кластер - разумеется держат.
Найти где находится pg_database в системном каталоге, его oid где-то в исходниках жёстко прописан. Затем прочитать pg_database и найти oid нужной базы - это и будет путь
которые, кстати, проходят напрямую, без транзакций
Если вы не делаете begin & commit - это не значит, что у вас нет транзакций.
fdw с точки зрения удалённого сервера ничем не отличается от других клиентов, рядовой libpq клиент. Две программы для возвращения места ФС я указал, на очень многих базах проверены.
за "всегда" ответить не могу, не сетевой администратор. Но ожидать подключения по ipv6 в 2018 году вполне логично и в hba пишутся 3 способа обращения для локальной машины.
У вас явно не те вопросы, чтобы суметь заметить разницу между ddr4-1866 и ddr4-2800. Разница есть, но не как между установить 1гб RAM или 4гб. Если специально не замерять - различий не заметите.
Согласуют скорей всего на 2400мгц как раз. Но надо смотреть конкретику, а лучше проверять.
99% к тому что согласуют, 1% откажутся работать вместе. 1% может быть завышенной оценкой вероятности, но изредка действительно встречается, что конкретная комбинация памяти, материнки и контроллера памяти по отдельности работают, а вместе именно в таком составе - нет.
https://en.wikipedia.org/wiki/Serial_presence_detect
стандартный кусочек энергонезависимой памяти, куда записаны поддерживаемые этим модулем памяти режимы работы. xmp - расширение стандарта от intel, куда обычно пишутся нестандартные (по JEDEC) настройки.
Да, подождать. От нескольких часов, лучше сутки.
Агрессивно привлекать внимание не дав вообще никому возможности даже прочесть вопрос, не то что ответить - я субъективно расцениваю как неуважение.
По хостерам и их собственным образам спрашивайте кого-нибудь другого. Может раньше у вас рейда вообще не было. Или вам ставили железный контроллер (ну или фейковый чипсетный в худшем случае) - эти разумеется не теряют сведения о синхронности дисков если не переставляли сами диски, да и если переставляли может лимитирована скорость фоновой синхронизации под механику.
С позиции ядра linux - инициализация нового массива форсирует фоновый ребилд этого массива как единственный возможный способ дальше жить.
После переустановки подсистема linux raid не знает, что там на дисках творится, откуда диски взялись и что на них написано. Следовательно необходимо перестроить весь блочный уровень mdraid. Это единственный возможный способ обеспечить синхронность массива.
