Дескриптор будет уничтожен. Потому последующий curl_setopt и жалуется. Переменная - нет, и будет содержать пустой zend_resource с невалидным type.
Лучше обнулить _ch явно после curl_close. Понятнее будет.
Впрочем соглашусь с ThunderCat , дизайн класса вызывает вопросы.
Для приведённого кода throw new Exception('Empty $_ch in MtargetOffers.'); недостижим никогда. Ни на первом ни на повторном вызове. Я уже написал почему.
идея в том, чтобы выбрать нужные 10 записей и только для них считать count по Unit, а не по всей таблице считать группировку и затем джойнить с нужными 10 записями. До появления lateral join это делалось как у вас в ответе дублированием условия, выносом условия в отдельный cte, или даже функцией. С lateral join немного удобнее это объяснять, в подзапросе в join появляется возможность сделать коррелированный запрос.
Да, в нормально спроектированной базе первичный ключ должен быть и да, его необходимо указывать явно. Так же как FK и прочие ограничения целостности. Потому что только разработчик схемы знает свои ограничения хранимых данных.
Счетчик в цикле не обязательно используется как индекс в массиве, так что всегда надо смотреть на ситуацию.
Так и я о том же самом пишу.
Из текста вопроса не следует (на мой взгляд), что вопрос касается исключительно работы с массивом в памяти. Вопрос про счётчик итераций.
Евгений Шатунов, потому что size_t - implementation-defined (гарантируется емнип вообще только 16 бит). Если вам заведомо необходимо 64-битное целое - то вам не по пути с implementation-defined вещами, вам нужно именно 64-битное целое.
если полей много - то тем более собирают необходимый запрос из необходимых частей (использованных пользователем фильтров), а не пытаются запутать планировщик описанием всего сразу.
rgzrgz, погуглите как найти установленные пакеты с конкретного репозитория. На память не подскажу.
И по этому списку пакеты от 7.2 будут в большинстве случаев иметь 7.2 в названии. А метапакеты - не будут иметь какой-то принадлежности в имени.
/etc/apt/sources.list.d/php.list ?
Это корректное место для адресов репозиториев, идентично /etc/apt/sources.list
А если мне нужен именно php 7.2. Это удалит поддержку 7.2?
Это удалит репозиторий. Пакеты останутся, но обновляться не будут.
А происходит у вас очевидно то, что вы добавили этот репозиторий, поставили пакеты типа libapache2-mod-php. По зависимостям прилетел 7.2. Прошло время. Вышел php 7.3. libapache2-mod-php теперь указывает на libapache2-mod-php7.3.
Совершенно очевидно apt хочет сказать, что для соответствия новым реалиям есть обновления - надо на 7.3 обновляться. Но upgrade это сделать не может, т.к. надо ставить новые пакеты. dist-upgrade предложит поставить 7.3
Если вы не готовы к 7.3 - то вам надо снести метапакеты без указанных версий, а на нужны проставить apt-mark manual метку
В wal пишутся и соответственно реплицируются изменения по всему кластеру целиком. Поэтому если потерян - то репликация встанет и пожалуется на жизнь в лог.
Одна из баз на мастере имеет размер 100гб на слейве 16гб.
А вы точно представляете, что хотите сделать?
Пользователь один, по какому критерию требуется фильтровать?