в каком ключе вести дальнейшую дискуссию в -hackers?
это будет как отдельный фич реквест (или баг репорт) с расчётом, что если наш патч пролетит мимо, то с локальным коммитом от Ctrl+C / Ctrl+D желательно решить вопрос.
> А вот если Вы будете настаивать на том, что это bug, то Вы можете увидеть это в следующих minor releases, причём во всех!
Даже если это баг фикс, не факт, что попадёт в минорные релизы - всё зависит от объёма правки
>> упоминание в доке
Для Вас (да и для всех, IMHO) — это наихудший исход, нет?
это самый простой и быстрый вариант, который, скорее всего, войдёт в минорные релизы.
>> vs. явное третье состояние в статусе команды (тэге)
Хотя этот исход — ещё хуже (я не смотрел, но это может потребовать изменения протокола и т.п.).
IMHO, это вообще "не выгорит". :(
соглашусь, но так правильнее всего
>> vs. явный разрыв соединения с клиентом как эмуляция этого третьего состояния
Я предлагаю альтернативу (если она технически возможна, я не смотрел) — не разрывать соединение, но в ответ на COMMIT (или даже отдельный statement с autocommit) не возвращать никакого тэга!
по сути как вариант с третьим состоянием
> В этом случае правильно написанный клиент должен понять, что это вариант "indeterminate state", и адекватно отреагировать.
Тоже как и с третьим состоянием надо обучать клиента, поскольку по протоколу, скорее всего, статус не должен быть пустым
> это будет как отдельный фич реквест (или баг репорт) с расчётом Понятно (как-то мало у Вас энтузиазма, IMHO). ;) Кстати, можно же в -hackers издевательски показывать repro, как за счёт этой "feature" primary можно "утащить" от синхронной (!) реплики сколь угодно далеко. ;) > что попадёт в минорные релизы - всё зависит от объёма правки Как повезёт, да. Ещё может попасть только в minors v12, например. :( > соглашусь, но так правильнее всего Может быть... но гораздо легче разорвать connection. :) > по сути как вариант с третьим состоянием Да. Если тут есть технические проблемы — просто забудьте о моём предложении. :)
Обсуждают сегодня