Слава ктулху, я не занимаюсь кодом, который лежит вне системы контроля версий.
Ну если припрёт оперировать гланды силами проктолога - скопировать, положить под гит, поправить, проверить diff, закоммитить, положить изменённые файлы обратно.
Давно тут разрешили редактировать комментарии и даже не писать примечание, что комментарий был изменён?
Не путайте открытый и проприетарный драйвера. Это две очень разные штуки.
А проблема легко может быть и из-за браузера и из-за пачки либ посередине. Попробуйте на актуальном релизе.
Вообще-то за прошедшие года уже stretch релизнулся и актуальный релиз это 9.0
Год драйвера это просто - примерно за полгода-год до релиза дебиана пакетная база замораживается и без серьёзных причин никогда на следующую мажорную версию более не апгрейдится. Соответственно весь софт в пакетах ровесник плюс минус от заморозки до релиза, затем только минорные и security обновления. Wheezy был заморожен 30 июня 2012 года.
Что есть "реальный" IP?
Адрес хоста, с которого открыт сокет? Это REMOTE_ADDR.
Для 127/8 как раз местоположение определяется элементарно - это _здесь_.
Адреса интерфейсов на хосте? Ну и где я с моими 127.0.0.0/8, 192.168.5.10/24, 192.168.15.2/24 нахожусь, по-вашему?
На уровне детализации "записать в переменную" многие сотни тысяч блоков - легко. Даже для глупого mysql, даже не рассматривая storage engine, где ещё вагон логики и несколько десятилетий научной работы человечества.
Покажите эту диаграмму преподавателю и спросите, до какого уровня надо детализировать выполнение. Никакого простенького цикла здесь нет. Вся эта машинерия выполняется для каждого запроса в отдельности, поэтому абстрактный блок "выполнение SQL запроса". верен.
Кстати, да. Для prepared statements диаграмма будет отличаться, если вы выключили активную по-умолчанию эмуляцию подготовленных запросов в PDO.
psql -f all_databases.sql
Делает в точности то, что написано в файле all_databases.sql - исполняет указанные SQL запросы один за другим.
Если этот sql был сформирован через pg_dumpall - то там будут запросы создания ролей, баз данных, подключения к этим БД и создания в них табличек с данными и прочих объектов. Дефолтно дампятся все БД, пользователи и т.д. Можно дампить не всё, опции есть.
Если дамп снимался через pg_dump - то другой файлик будет, с одной конкретной БД.
Но восстанавливать объекты выборочно нельзя.
Доступ к аккаунту суперпользователя, разумеется, ограничен. Судя по тексту ошибки первым подходящим правилом в вашем pg_hba.conf является проверка peer аутентификации (при подключении через unix-сокет). Чтобы её пройти, надо быть залогиненым в системе как одноимённый пользователь. sudo -u postgres т.е.
CityCat4: ага, я-то думал, что i7 мобильные как раз с 4 ядрами и есть, шёл смотреть именно сколько нынче ядер у мобильных i5, а тут вот как.
Nekto_Habr: а что ещё? TDP одинаковый, контроллер памяти одинаковый, периферия одна и та же - cpu ведь ровесники. С вероятностью в 99% это даже физически один и тот же чип, отбраковка с неисправным 1мб блоком L2 кеша либо не укладывающийся на чуть более высокой частоте в требуемый теплопакет.
./ -- проект
web/ -- сюда настроить смотреть веб-сервер
web/index.php -- сюда завернуть все динамические запросы
web/css/
web/img/
web/js/
vendor/
composer.lock
composer.json
.git/
-- любые другие директирии и файлы с кодом проекта так же здесь, а не в document root'е
Проверка массива в ядре, для её запуска достаточно сделать: echo check > /sys/block/mdX/md/sync_action
За результатом следить в dmesg, за прогрессом работы - в /proc/mdadm
Проверяет, естественно, только блочный уровень. linux raid не знает, что у вас на нём размещено. Вдруг lvm или вообще образ виртуальной машины. А то для каких-нибудь нужд и сразу данные.
Под дебианом есть скрипт /usr/share/mdadm/checkarray , вызов которого при установке пакета mdadm добавляется в крон раз в месяц. Но суть его сводится в конечном итоге к тому самому sync_action
Ну если припрёт оперировать гланды силами проктолога - скопировать, положить под гит, поправить, проверить diff, закоммитить, положить изменённые файлы обратно.